• Голос записывается через I2S-микрофон и сохраняется во флеш-память или на SD-карту, так как аудио быстро расходует RAM.
• Сохранённый аудиофайл отправляется по HTTPS в LLM (в тексте чаще упоминаются Gemini или OpenAI).
• Промпт включает аудио и системный промпт со списком «инструментов», которые допускаются к вызову.
• Нейросеть решает, вызывать ли инструмент, и возвращает структурированный JSON с параметрами; прошивка исполняет заранее описанные действия.
• Задержка в схеме «записали — отправили — дождались ответа» оценивается в несколько секунд; ускорение через WebSocket требует дополнительного сервера между ESP32 и LLM.
• Отдельно отмечены сложности HTTPS на ESP32 (WiFiClientSecure) и ключевой UX-вопрос wake-word; как простой вариант «пробуждения» приводится двойной хлопок.

Почему это важно: В описанном примере голосовое управление строится вокруг Function Calling: нейросеть выбирает инструмент и возвращает JSON с параметрами, а устройство выполняет только заранее описанные действия. Это показывает, как голосовая команда превращается в JSON-действие и уменьшает объём ручной логики в прошивке. Подход делает возможными более «разговорные» команды в пределах заданных рамок, но усиливает зависимость от контекста и работы облачных сервисов.

На что обратить внимание: В тексте подчёркнуто, что хранение аудио на флеш/SD решает проблему RAM, но добавляет задержку и накладывает требования к работе с файлами и соединением. Отдельной зоной риска названы долгие HTTPS-соединения на ESP32 и способы стабилизации через тайм-ауты, закрытие соединений, переподключения и программную перезагрузку. Для пользовательского опыта ключевым остаётся wake-word и сценарий пробуждения, поскольку локальные варианты распознавания описаны как слабые, а альтернатива предлагается физическим жестом.