12 ready-to-adopt ESPHome configs: ESP32-P4 voice assistants, e-paper calendar, LVGL touch dimmers, Alarmo keypad, HUB75 matrix, rotary dials

I’ve published the ESPHome configs for the devices running in my home, cleaned up so anyone can adopt them:

GitHub - gbroeckling/esphome-devices: Ready-to-adopt ESPHome configs: ESP32-P4 voice assistants, e-paper calendar, LVGL touch dimmers, Alarmo keypad, HUB75 LED matrix, rotary dial controllers · GitHub

What’s in there:

  • Voice assistants: two ESP32-P4 builds (incl. Guition dev board — P4 voice configs are still rare) and an M5Stack Atom EchoS3R (with the gotcha documented: micro-wake-word needs ESPHome >= 2026.7 or the device is deaf)
  • Displays: e-paper calendar (PaperD.ink), XIAO ESP32-C3 e-ink status display
  • Touch panels: 480px LVGL light dimmer, and an Alarmo arm/disarm touch keypad
  • LED matrix: HUB75 32x64 countdown timer + 64x64 on ESP32-Trinity
  • Controls: two round-display rotary dial controllers (Makerfabs/CST826), and an audio feedback generator for Alarmo

Every yaml is self-contained: WiFi via !secret, no hardcoded credentials, and each carries dashboard_import so you can pull it via packages: or adopt straight from the ESPHome dashboard:

packages:
  device_name:
    url: https://github.com/gbroeckling/esphome-devices
    file: <folder>/<folder>.yaml
    ref: main

Each device folder has a short README with the board and any quirks. MIT licensed — take what’s useful. Feedback and PRs welcome.

Looks interesting. I may try a few of those at some point.

Update: photos added, and I’ve written an honest status into every config.

When I first posted this it was a table of links. Since then I’ve been through all 13 configs and added a “Where this actually stands” section to each one - what’s verified on hardware, what merely compiles, and what’s outright broken. Plus real photos of the devices running.

Easiest way to use any of them - every config carries dashboard_import, so you can paste this straight into your ESPHome dashboard and hit Adopt, no file editing, and you get your own API key and OTA password:

github://gbroeckling/esphome-devices/<folder>/<folder>.yaml@main

All thirteen are running builds, and each README records the date it was last verified on hardware - the M5Stack Atom EchoS3R and ReSpeaker Lite voice satellites, both e-paper calendars, the two HUB75 matrices, the rotary dials and the touch panels. The one exception is the window opener, which is still in progress: hardware wired, Home Assistant logic built, not yet a cover entity.

Where something has a real caveat that would bite an adopter, it’s written into that device’s README rather than glossed over - a pinned ESPHome version on the CST826 dials, and the fact that some 4848S040 panels ship with an empty ota: block and need one USB flash before they’ll ever update wirelessly.


Four things that cost me real time, in case they save you some:

1. Wake-word satellites go silently deaf on ESPHome 2026.2.1. The bundled tflite runtime can’t load current microWakeWord models. It throws Failed to allocate tensors for the streaming model, the wake engine stops, and the device otherwise looks completely healthy - connected, logging, responding. It just never hears you. This cost me months on the Atom Echo. Build wake-word devices on 2026.7.3 or newer.

2. But you can’t just move everything forward. The cst826 touch component on my Makerfabs round dials only builds on the older branch. There’s a genuine version split in the repo: wake-word needs new, some touch needs old.

3. ESPHome 2026.7 broke LVGL rotation twice. Rotation moved from display: to lvgl: - and once LVGL owns rotation you must delete the touchscreen: transform. Keeping both double-transforms every tap, so every button on the screen fires the same wrong entity. That symptom is very confusing if you don’t know the cause.

4. “OTA successful” can lie. I’ve had a flash report success while the device kept running old firmware. Always read the compiled on stamp from the live log before you believe it.


5. E-paper keeps its last image with no power - so put a timestamp on it.

The screen alone can never tell you whether what you’re reading is current, which is a property of the medium rather than of any particular build. Both e-paper configs here render uptime and an “updated HH:MM” stamp for exactly that reason. On e-paper that’s a design requirement, not a nice-to-have.


On ESP32-P4 voice, since people keep asking: I do not yet have a single P4 doing both microphone and speaker. What runs here is a two-board pair - one P4 has the mic and wake word, and relays the spoken reply to a second P4 that has the speaker. It works, but it’s a workaround, not a design. One of my Guition P4 panels has a speaker port with nothing wired to it and no built-in mic at all. If you want one board that hears and answers today, use an ESP32-S3.

MIT, no strings. Issues and Discussions are open - if one of these works on a board I don’t own, or you fix something I’ve flagged as broken, I’d like to know.