A plushie of Senil Sen's Blog

Google Home Mini to ESPHome - Hardware Selection

If you didn’t catch me posting about this earlier this month, I’ve been thinking about turning my 1st gen Google Home Mini (NOT the Nest Mini, that’s the second gen) into a ESPHome-powered voice assistant to link up to my Home Assistant. There’s many, MANY steps involved here, from just designing the damn circuit board to fleshing out the workflow via Home Assistant, but every project has got to start somewhere.

And hardware selection, since I have zero good reference points as far as I know, is the best place to start.

Since this is so goddamn long, here are some quick links to jump to different main sections:
The Google Home Mini Itself.
The Brains of the Operation.
The Audio System.
Some Bonus Features for the Mini.
Timeline and Challenges.

Senil dazed and drooling, with a loading icon above him. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil dazed and drooling, with a loading icon above him. Art by Dragonjourney

The Goal

The ultimate goal of this project is to design, develop, and test a more-or-less drop-in mainboard for a first-generation Google Home Mini that’s based on ESPHome, with minimal-to-no chassis modifications so it truly is plug-and-play.

ESPHome, a project by Nabu Casa (who also works on Home Assistant), is a platform to easily add DIY devices to Home Assistant. The goal is simple programming via YAML, and every device has a standardized “firmware” of a sorts for end users to add on to. Since this is going to be a brand-new implementation, I get the joy of developing that “firmware” myself.

OK, it’s not REALLY firmware, it’s just a way to set up board-level naming and such so it’s easier to work with in YAML, but still. I’ll be the one responsible for this shit. Yippee!

So, let’s talk about the main parts that will be worked on.

The Google Home Mini Itself

If you’ve never cracked open a Google Home Mini, you’re missing out on some clever engineering work. The mainboard itself is incredibly compact, with a very, VERY thin PCB and support components on both sides. The metal frame that it sits on (which the speaker points up at to get that 360 degree mono audio) is perfectly crafted for the big capacitors and speaker connection port to sit in, without touching the rest of the board. It’s clever, really, but that means I have to work around the existing metal frame.

There’s also a tiny little board where the micro-USB plug sits that sends in power, has an itty bitty reset button to wipe the configuration of the device, and a physical switch to turn the microphone on and off. I need to investigate the board further, but it looks like the board only sends through 5V USB power, the reset button, and the mic on/off switch. Since I want users to be able to update the Home Mini without having to tear it apart, I’ll also end up designing a new board that uses USB-C instead and passes through data to the mainboard.

Regarding that microphone on/off switch, I can’t tell if it ends up physically disconnecting the microphones somehow, or if it’s just a software thing. Since I’ll be designing a new power board, I might as well try to make it a full-on mic disconnect, instead of a software “stop listening, damnit.” If I can’t find a way to physically disconnect the microphones, then I’ll get the joy of figuring out where I can software disconnect things.

Senil lying face-down on the ground, with a low battery symbol above him. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil lying face-down on the ground, with a low battery symbol above him. Art by Dragonjourney

There’s a handful of LEDs that the Mini lights up when it’s thinking of your request, as well as change as you adjust volume via two… capacitive? pressure? pads on the left and right sides by the microphones. I have no idea how I’m gonna handle those with ESPHome, but there’ll be four nice little lights sitting there regardless.

The Brains of the Operation

There are several options at my disposal for making this ESPHome board - I could use an ESP32, I could toss in an RP2040 and a separate WiFi chip, I could do some wacky third thing - but of the existing Home Assistant Voice examples, all of them use some version of the ESP32-S3 chip. There are also plenty of other products that make use of it, so I’ll at least have a reference point for how the thing works.

However, I do still have a choice to make. I can get the ESP32-S3 chip itself, and add on the necessary support components as I want - being the flash memory, wireless antenna, and all that jazz. Or, I can get a complete module that contains the ESP32-S3, the flash memory, and - if I want - an on-module antenna. There’s a version with a u.FL snap too, but then I’d have to figure out where the hell I’m going to shove a separate antenna into this tiny ass thing.

Given that I don’t know what the hell I’m doing - I’m a controls engineer by trade, not a PCB designer - I’ll be going with the module that includes (most) of what I need for the brains of it all. There’ll be plenty of other support components for the module, but nowhere near as many for me to manage compared to using the individual chips.

Senil with his hands on his head, mouth wide open in fear. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil with his hands on his head, mouth wide open in fear. Art by Dragonjourney

The Audio System

What good is a mainboard that hooks up to ESPHome that I want to be a voice assistant that can’t handle audio? Fortunately the Google Home Mini comes with its own 4-ohm 3-watt speaker that, while it doesn’t sound incredible, is at least serviceable and does alright given its dimensions. It’s casing is actually molded to wrap around other components it sits by, so that’s a design constraint on some components. It also isn’t hardwired into the existing mainboard, which makes my life a LOT easier.

So while my speaker situation is well managed… I still have some microphones to deal with. The Google Home Mini gets away with just two - one on each side, with the case funneling the microphones into a more directed fashion for… reasons, so I have faith I could get away with just two as well. If I added more, I’d need to both figure out where they’re going to go, as well as how they’re going to listen in. Two good mics should be more than enough on that front.

But wait a second… this is going to be a voice assistant that does wake word stuff on its own (I could pipe an audio stream to Home Assistant, but that means keeping an active network connection 24/7), and there are only so many resources to go around. I can’t just program in beamforming algorithms and other audio processing systems into a chip that’s already burdened with everything else that relates to being a voice assistant.

Enter the XMOS XU316

The XMOS XU316 is a powerful microcontroller with one job in mind - voice processing. It has a ton of useful, baked-in tools that would be way too annoying for me to program and understand on my own - let alone implement into an ESPHome system that I’m already unfamiliar with - and passes through clean audio that the ESP32 can work with (by shoving it to Home Assistant).

The XU316, per XMOS’s website for it, does acoustic echo cancellation via it’s two-mic input, runs automatic gain control, handles noise supression, and can pass all of this out via I2S. Oh, and it’s also technically a USB Class 2 audio device. Not like that’s something I’ll be using here - the ESP32-S3 can work with I2S for audio, so the XU316 will just pass data along that way.

Mostly easy-peasy! A chip that handles (most) of what I need, easing the burden from the ESP32 that’ll be handling a built-in wake word and networking. And may or may not be managing additional features that I would love to integrate, but may or may not be able to.

Some Bonus Features for the Mini

Senil flexing his biceps, smirking. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil flexing his biceps, smirking. Art by Dragonjourney

There are a variety of nice, quality-of-life features that’ll take this board from a basic drop-in, and turn it into a proper upgrade built for Home Assistant from the get go. All of these are things that I would LOVE to add, but simply might not be able to. Both because of how little space I have to work with, and because I probably don’t know what I’m doing.

Smart Home Wireless Protocols

Something that the Google Home Mini lacks is any ability to connect to act as a hub for smart home tech. It’s merely a voice assistant, it can’t connect to jack shit without you owning a separate hub to handle smart home protocols like Zigbee, Z-Wave, or Thread.

And so, a nice quality of life upgrade would be to build in a router for Zigbee and/or Thread to the mainboard. This at least gives the board a value-add, outside of “I want to keep this thing but de-Google it,” something that I think is important for any kind of project like this. If your setup works as-is with Google Home and/or Home Assistant, why would you bother modifying your Home Mini to do this?

Zigbee and Thread

Zigbee is the obvious choice to add as a router. It has a wide ecosystem to work with, and can easily talk to Home Assistant via the MQTT integration. It’s also very well understood, and I’d have plenty of reference implementations to work with, cutting down on the labor involved in integrating the damn thing.

Thread is up and coming, built to be low power and tightly integrated with the Matter ecosystem. I’ve personally taken interest in Matter largely because of how comprehensive it is, but I take serious issue with how Google, Apple, and Amazon - all members of the organization that develops the Matter specifications - neglect to implement the Matter spec in full. Only Samsung’s SmartThings and Home Assistant fully implement the latest Matter specs, and giving this Google Home Mini an upgrade to not only act as a hub for smart devices, but to have built-in support for a growing protocol with Home Assistant would be a good value add in my opinion.

I can, of course, set it up to do either Zigbee or Thread, since both use 2.4GHz for networking, which would hopefully cut down on the design work and hardware integration.

Z-Wave

Z-Wave is the final option available to me, and it’s one that I’m a little more hesitant to include. Z-Wave has nowhere near the ecosystem support that Zigbee has, nor does it have the growth that Thread/Matter enjoys, but it does have a major advantage over both. It doesn’t use the increasingly cluttered 2.4GHz channels, instead opting for lower bandwidth and less cluttered sub-1GHz bands. Sure, Z-Wave isn’t as “fast” as Zigbee or Thread can be, but it can boast a much better coverage radius than either, ideally meaning it needs fewer permantently powered devices to maintain a good mesh network with wide coverage. Hell, the newest Z-Wave specification has an effective radius of over a kilometer.

I don’t think any Z-Wave implementation in a Google Home Mini is going to have quite that range, but it would boast a large range and (ideally) less clutter than Zigbee or Thread.

Z-Wave does have a downside in that exactly one company owns the designs for Z-Wave hardware and radios and shit, severely limiting my hardware selection when it comes to the “how the fuck do I shove parts inside this thing” step of this project.

Built-in Sensors

This is much lower on my desire list than somehow baking in a smart home protocol, but having some sensors that are automagically included would be a nice benefit. I don’t know what I could realistically add - temperature and humidity would be easily influenced by the heat of the other components, presence detection would be difficult without modifying the chassis, same as ambient light - but if there’s the space to add something, and make it something useful for where you might put this kind of thing, then I’d love to add it.

This could easily be adding many more support components though, and figuring out how to cram even more into the already probably crammed mainboard would be… Difficult, to say the least.

Timeline & Challenges

Senil pointing towards the viewier, winking. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil pointing towards the viewier, winking. Art by Dragonjourney

There isn’t really any “goal” for when I want this thing done. All I know is that step one is to lock down exactly what parts I need, and then get to work designing circuit boards in some sort of PCB CAD software. And… then hope that I can get these boards built and assembled for relatively cheap despite the ridiculus tariffs in place.

I would love to both open source the designs and programming for this project, and maybe sell the boards myself (acting as an intermediary between some PCB manufacturer and assembler, programming and testing them, and shipping them off) so folks can get in on de-Googling (and de-Amazoning) their smart homes and voice assistants.

Having a mostly drop-in board that Just Works out of the box (barring Home Assistant Voice quirks, I can’t control those) and hopefully has a high partner approval factor so it’s easy to get used to would be fantastic. And maybe, just maybe, my design will lead to folks spinning it off and making similar drop-ins for other voice assistant products from Google, Apple, and Amazon.

The best time to build our own assistants was years ago. The second best time is right here, right now.

Thank you

If you’re reading this, you made it to the end of the (very long) post. Thanks for reading this gigantic rambly nonsense. If you have circuit design experience, know of a good PCB factory and assembler, or have projects you know of that would be a great source of inspiration, PLEASE feel free to reach out to me. I’m available in a lot of places, so poke me on Bluesky, Fedi, Telegram, Discord… even email, if you want!

Senil hugging a big pink heart. Art by [Dragonjourney](https://www.furaffinity.net/user/dragonjourney)
Senil hugging a big pink heart. Art by Dragonjourney