MiciMike turns a dead Nest Mini into an open voice assistant

The enclosure is the constraint that shapes everything

The project is a drop-in replacement Printed Circuit Board for the Google Nest Mini, specifically the second generation unit with a barrel connector charging port. The whole point is reuse: the goal is to convert or repurpose an old Google Nest Mini smart speaker into open source hardware for voice control of Home Assistant, or for media player speaker output for Music Assistant.

What makes that possible in a predictable way is the reference design it copies. The board is described as mostly hardware compatible with the Home Assistant Voice Preview Edition, also known as Home Assistant Voice PE, which Open Home Foundation released as open source hardware design in collaboration with Nabu Casa. The project aims to follow that standard for PCB designs and specifications.

The catch is stated plainly in the same paragraph. The main difference comes from constraints defined by the Google Nest Mini enclosure and components, meaning the design will be limited by the same type of physical capacity inputs as the original hardware from Google. There is no room for a larger radio, a different connector or a bigger battery.

That is the central trade of the project. You get to keep the case, the speaker and the industrial design of a device Google made, and you inherit every dimensional and thermal decision Google made in it. There is also a sister project for the first generation Google Home Mini, which has a Micro-USB charging port, so the same conversion exists for both generations of the speaker.

Three Espressif chips, and one that is optional

The current architecture is built around three Espressif microcontrollers, and the split of responsibilities is specific.

The ESP32-S3 handles Wi-Fi, Bluetooth LE and onboard wake-word detection. Onboard wake word matters for a voice assistant because it means the device can listen for a trigger locally rather than streaming audio continuously to a server, which is the mechanism the Home Assistant voice control documentation describes for wake word.

The ESP32-P4 is the high-performance audio and signal processing controller. The documentation is explicit that the ESP32-P4 replaces the previously planned XMOS XU316, and that it is intended to handle the microphone and audio pipeline and future local processing such as noise suppression, acoustic echo cancellation, interference cancellation and automatic gain control. The repository still carries an xmos.kicad_sch file, which is the remnant of the earlier plan, and the project description itself mentions XMOS integration. Firmware for this revised architecture is still under development.

The third chip, the ESP32-C6, appears in only one of the two planned hardware variants. The full version includes an ESP32-C6 for Wi-Fi 6, Bluetooth LE and 802.15.4, which enables OpenThread Border Router functionality. A second version omits the ESP32-C6 for installations that do not require OTBR or Thread border router support.

That single optional part is the difference between a voice speaker and a Matter-era smart home radio, and it is the main reason to think about which variant to fabricate rather than ordering the full board by default.

The repository is a KiCad project, not a build script

There is no install command, no firmware build in this repository, and no board ordering step documented here. The deliverable is a hardware design, and the top level file listing shows what that means in practice.

The design is in KiCad. There is a nest-mini-v2-drop-in-pcb.kicad_pcb board file, a matching .kicad_sch schematic, a .kicad_pro project file, a .kicad_dru design rules file, a rendered nest-mini-v2-drop-in-pcb.pdf, and a fp-lib-table pointing at the footprint libraries. The schematics are split by function across several files: audio.kicad_sch, esp32.kicad_sch, esp32c6fh8_sch.kicad_sch, leds.kicad_sch, power_handling.kicad_sch, and the legacy xmos.kicad_sch. A power_handling.kicad_sch-bak file sits alongside the live one.

Beyond the design files there is a parts directory, a pics directory, a reports directory, a MiciMike.yaml file, and PCB_connections.xlsx, which is a spreadsheet of the board connections. The components in parts/ and the spreadsheet are what you would work from when costing the build and checking the design against the parts list.

Because there is no build script, the way to use this project is to open the KiCad project, inspect the schematic, and take the design to a fabricator yourself. The project states its scope is not to develop new features or functions for the ESPHome firmware, and points anyone who wants that to the firmware development of the Home Assistant Voice Preview Edition and to the upstream ESPHome mainline code.

Firmware lives in other repositories

The division of labour between hardware and firmware is clear enough to be worth stating precisely, because it determines what you have to build yourself.

This repository is the board. The firmware that runs on it is developed elsewhere, and the README points to three places: the ESPHome repository for the Home Assistant Voice PE, the ESPHome mainline code, and the ESPHome feature requests repository. The stated scope note says the goal of this project and repository is not to develop new features or functions for the ESPHome firmware.

That makes sense for an open hardware project that aims to follow an existing standard, and it also means a person building this board inherits the firmware situation of the Voice PE project, including whatever is finished there. Since the ESP32-P4 architecture is described as still under development, a board built today from these sources is a board that will need firmware work.

The project is also honest about asking for help. It explicitly requests collaboration from people with experience in PCB layout design, especially PCB routing, ground pouring, or noise sensitive digital and analog layouts. A board that mixes a Wi-Fi and Bluetooth LE radio, a high performance audio controller, microphones, and power handling is exactly the kind of design where layout expertise is the difference between a working board and a noisy one.

For background, the documentation points to a Home Assistant community forum thread on the topic, and the project takes concept inspiration from Onju Voice while aiming to follow the Open Home Foundation standard instead of copying a specific board.

Hardware compatible, but not a clone of the reference design

It is worth being precise about the relationship between this board and the Home Assistant Voice PE reference design, because the phrase hardware compatible in the documentation invites the wrong conclusion.

The intent is that the two are functionally similar, so that software written against one has a good chance of working on the other. The stated differences come from the Nest Mini enclosure: physical capacity, the components Google chose, and therefore what fits inside the case. A board that reproduces the reference design exactly would be a different product with a different case.

That constraint has consequences beyond fit. The Nest Mini has a specific speaker, a specific microphone arrangement, a specific power input through a barrel connector, and a specific set of LEDs, which is why the design has a separate leds.kicad_sch. Each of those is a decision Google already made that the board has to work within, and the audio pipeline in particular has to be tuned to whatever microphone and amplifier arrangement the original enclosure provides.

For someone building this, the practical workflow is to compare the schematic against the reference design and work out what the enclosure forces you to change. The reports directory and the PDF rendering of the board are the artefacts to look at first.

The project also notes that the hardware can probably be used with other applications with other firmware, since it is based on the popular Espressif ESP32 platform. That is a reasonable expectation, but it is stated as a probably, and the design's two planned variants, the optional ESP32-C6 and the enclosure fit, are both tied to the voice assistant use case.

What a board like this costs you to actually build

There is no stated parts list, no fabrication quote and no assembly service in the documentation, so the honest way to frame this is as a set of engineering tasks rather than a purchase.

The first task is fabrication. The design is released as KiCad sources with a board file and a PDF, so you would send those to a fabricator and specify the process yourself. The number of layers, the controlled impedance needs and the size of the ground pour all come out of the design rather than out of a supplier's standard options.

The second task is sourcing. The parts directory in the repository is where the component list lives, and the presence of a parts/ directory with the design suggests the author has done that work, but the README does not enumerate costs or availability. An ESP32-S3, an ESP32-P4 and an ESP32-C6, plus the audio front end, are all components with their own supply considerations.

The third task is assembly and rework, which for a board of this density is not trivial, and the fourth is the enclosure work: the board has to go into a Nest Mini case, which means disassembly, possibly case modification, and reassembly. Later generations of Google's speakers are different designs from the second generation this board targets, and the enclosure fit is the project's own stated limit.

The fifth task is firmware, which as described above means riding on the Voice PE and ESPHome development rather than having something turnkey.

Against that, the payoff is a device that runs your own local assistant with no Google account and no Google cloud in the loop, in a case that already looks the part on a shelf. For the right person that is worth it; for someone who wants a working voice assistant this afternoon, it is not close.

When this project is the wrong answer

Four situations rule it out.

The first is if you want a product rather than a project. There is no assembled unit to buy, no vendor to return to, and firmware described as still under development. Buying a supported voice assistant with a local mode is a different and much shorter path.

The second is if you do not already own the Nest Mini. The entire premise is repurposing hardware you already own, since a new Nest Mini is no longer sold in a form this board fits comfortably, and buying a used one just to gut it is a strange economics.

The third is if you need Matter or Thread over the air in the enclosure. The board can do it, because the full variant includes the ESP32-C6 with 802.15.4 and OpenThread Border Router capability, but you are building a border router into a speaker case, which raises the antenna and enclosure questions that the documented limitations allude to. A dedicated Thread border router is a different product.

The fourth is if you want new firmware features. The project is explicit that developing new features or functions for the ESPHome firmware is out of scope, and that work belongs in the Home Assistant Voice PE firmware repository and upstream ESPHome. If your interest is the software rather than the hardware, this repository will not get you there.

The alternative worth naming is the reference design itself. The Home Assistant Voice PE is a finished product with a working enclosure, an established supply chain and a firmware team behind it. The case for this project is entirely about reusing hardware you already have and avoiding Google account dependence, and if you do not have the hardware, the reference product is the better answer. The licensing is CERN-OHL-S-2.0, a hardware licence that permits modification and manufacture of derived boards, which matters if your plan involves a run rather than a single build.

Editorial conclusion

nest-mini-drop-in-pcb fits a maker who already owns a Nest Mini, wants local voice control through Home Assistant without a Google cloud dependency, and is willing to fabricate a board and swap it into the enclosure. It is the wrong choice if you want a finished product, since the firmware for the current architecture is still under development and the project explicitly excludes new ESPHome features, and it is the wrong choice if you do not own the hardware, since the whole value proposition is reusing an enclosure Google will otherwise retire. Before committing to a fabrication order, check three things: the schematics in the repository, since the design is released as KiCad sources, the parts directory for what you would actually have to buy, and the two hardware variants, since the version with the ESP32-C6 adds Wi-Fi 6, Bluetooth LE and 802.15.4 for OpenThread border router use that a plain voice assistant does not need. The last push was on 2026-10-20 and the only tagged release is v0.9-test-batch from 2025-07-05, so treat the design as a work in progress rather than a finished board.

Frequently asked questions

Official sources

1. iMike78/nest-mini-drop-in-pcb on GitHub
2. License: CERN-OHL-S-2.0
3. Project website
4. README
5. Releases