Starmoon: a deprecated ESP32 voice companion and what its README still tells you
A conversational, AI device + software framework for companionship, entertainment, education, healthcare, IoT applications, and DIY robotics. Built with Python, NextJS, Arduino, ESP32, LLMs (GPT-4o), Deepgram STT and Azure TTS 🤖
At a glance
- What is it?
- Starmoon is a GPL-3.0 firmware plus web stack for a palm-sized conversational device built on an ESP32-S3, GPT-4o, Deepgram STT and Azure TTS. The repository is deprecated and points readers to ElatoAI, so the useful question is not whether to adopt it but what its structure and pin map still teach.
- Who is it for?
- Starmoon is worth reading, not deploying. Anyone reverse-engineering a two-way voice loop on an ESP32-S3 should study the pin table in the README and the Config.h board flags, because those are the parts that survive deprecation.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 172 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Starmoon was built to do, and for whom
The README frames Starmoon as an affordable, compact AI-enabled device you can carry and talk to. The stated goals are companionship, emotional support and personalized learning assistance, with a deliberate pitch against screen-based assistants: the project says its intention is to give your eyes a rest. The hardware list makes the audience concrete. This is aimed at people willing to solder a Seeed Studio Xiao ESP32S3, an INMP441 microphone, a MAX98357A amplifier, a small speaker, an RGB LED and a button onto a prototype board, then print a case from case_model.stl. The repository also carries topics for IoT, DIY robotics and voice assistants, so the second audience is engineers who want a reference implementation of a realtime voice loop on a microcontroller rather than a finished product. The feature list claims cost-effectiveness through off-the-shelf parts, real-time emotion analysis from conversation, and local self-hosting for data privacy. Those are claims from the README, not measurements, and the deprecation banner at the top of the same file undercuts all of them for new adopters.
The deprecation notice is the first thing to read
The README opens with a warning that Starmoon is no longer actively maintained, and directs readers to ElatoAI at github.com/akdeb/ElatoAI. The stated reasons are improved WiFi and two-way voice audio reliability, global availability and a production-ready architecture. The repository metadata is consistent with that: the last push is dated 2026-03-27 and no releases were retrieved. There is no migration guide, no deprecation timeline and no note on whether the hosted backend at starmoon.app still issues API keys. That gap matters because the prerequisites section tells you to log in to starmoon.app and copy an API key from the settings page before the firmware is useful. A project that is deprecated but still instructs users to depend on a hosted service leaves an unresolved question: the firmware may build fine and still fail at the first request. Treat the repository as a frozen artifact, and treat any live endpoint it mentions as something to verify yourself before you plan around it.
The hardware pin map is the most durable part of the repository
The README publishes a full wiring table for two targets, the Seeed Studio XIAO ESP32S3 and a generic ESP32-S3. The I2S microphone block assigns SD, WS and SCK to D0, D1 and D2 on the XIAO, or GPIO 14, GPIO 1 and GPIO 4 on a generic board. The I2S output block assigns WS, BCK and DATA to D5, D6 and D4, or GPIO 5, GPIO 6 and GPIO 7. The LED channels sit on D7, D8 and D9, or GPIO 9, GPIO 8 and GPIO 13, with the button on D10 or GPIO 2. One detail is easy to miss: the speaker's SD (shutdown) line has no generic ESP32-S3 equivalent, so a plain devkit loses that control. The README also notes that on the XIAO the lithium battery connects directly to the back of the board. This table is the kind of information that stays accurate after a project stops receiving commits, because it describes wires rather than software. If you are designing your own voice device, it is the section to copy.
How the firmware is selected and flashed
The build path runs through VS Code with the PlatformIO plugin. Board selection happens in two places that must agree. In firmware/src/Config.h you uncomment one board define and comment the others; the README shows USE_NORMAL_ESP32_S3, USE_XIAO_ESP32_DEVKIT, USE_XIAO_ESP32, USE_NORMAL_ESP32 and USE_ESP32_S3_WHITE_CASE as the available options. In firmware/platformio.ini you comment out the [env:seeed_xiao_esp32s3] block and uncomment [env:esp32-s3-devkitm-1] if you are not using the XIAO. Both environments declare platform = espressif32, framework = arduino and monitor_speed = 115200. The duplication is a real failure mode: set the define in Config.h without editing platformio.ini and you get a build for the wrong board, which usually shows up as silent I2S or a dead LED rather than a compile error. The README presents the two edits as sequential steps, which is the correct order, but nothing in the toolchain enforces that they match. The architecture implied by the repository layout is two halves: Arduino firmware in firmware/, and a Next.js frontend with a Python backend elsewhere in the tree, with the ESP32 streaming audio to a server that handles speech recognition, the language model and speech synthesis.
The voice pipeline depends on three external services
The repository description names GPT-4o for the language model, Deepgram for speech-to-text and Azure for text-to-speech. That means the device itself does very little inference. Audio leaves the ESP32, gets transcribed, is answered by a hosted model, and comes back as synthesized speech. The README's claim of local self-hosting and data privacy sits awkwardly against that design, because self-hosting the application does not remove the third-party services unless you replace them. The emotion analysis feature is described as understanding and analyzing insights in your emotions through your conversations in real time, but the README does not explain the mechanism, the model, or what data is retained. For a device marketed around companionship and emotional support, that is the thinnest part of the documentation and the part a privacy-conscious adopter should press on hardest. The same applies to the Trends Dashboard shown in the screenshots: the README presents it visually without describing what is stored or how it is computed.
Where Starmoon is the wrong choice, and what ElatoAI changes
If you need a device that works tomorrow and keeps working, Starmoon is the wrong tool. The README says it is unmaintained, and the prerequisites route you through a hosted API key whose availability is not guaranteed. Anyone building a product, a classroom deployment or a care setting should not start here. The named alternative is ElatoAI, and the difference is stated in the deprecation notice itself: the author says ElatoAI builds on ideas explored in Starmoon with improved WiFi and two-way voice audio reliability, global availability and a production-ready architecture. That is a maintenance and reliability difference, not a change of category. Both are ESP32 voice devices. The practical distinction is that Starmoon is a snapshot with a published pin map and a two-file board selection process, while ElatoAI is the line the original author kept working on. If you want the wiring reference, Starmoon is fine. If you want something to build on, the README's own recommendation points elsewhere.
Licence and the cost of keeping a fork alive
Starmoon is GPL-3.0. If you fork the firmware or the application and distribute the result, the copyleft terms apply to the derived work, which is a different proposition from a permissive licence for anyone planning a closed product. This is a description of the licence identifier in the repository, not legal advice; read the full text at gnu.org before you decide. The maintenance cost is the sharper issue. With no releases retrieved and the README declaring the project inactive, a fork means owning the PlatformIO environments, the Config.h board matrix, and the integration with Deepgram, Azure and GPT-4o yourself. The API key flow through starmoon.app is the first thing likely to break, since it depends on a service the project no longer maintains. Budget for replacing that with your own backend endpoint before you budget for anything else.
Editorial conclusion
Starmoon is worth reading, not deploying. Anyone reverse-engineering a two-way voice loop on an ESP32-S3 should study the pin table in the README and the Config.h board flags, because those are the parts that survive deprecation. Anyone who wants a maintained device should start at the ElatoAI repository the README names instead. Before touching either, confirm the current status of the Starmoon API key flow, since the README instructs users to log in to starmoon.app for a key and a deprecated project may not keep that service running.
Community notes