Вот интересно, почему решил, что проблема на стороне клиента (Java), а не сервера (Arduino)?
Давай уже тогда исходники и с ардуинки, чтобы еще два дня не биться.
Ага, цель хорошая :) Единственное, я когда это делал, использовал bluetooth, в этом случае не нужно писать веб-сервер, да и вообще почти писать не нужно.
На RPi ставишь HomeAssistant, к ардуинке подключаешь Bluetooth-модуль, заливаешь готовый скетч и управляешь чем хочешь.
можно организовать клиента который будет слушать внешний сервер
именно так и организован веб-сервер внутри, он слушает порт. Конечно можно сделать клиента, который будет слушать клиента, который будет слушать клиента, который будет слушать сервер и так пока не надоест :) Вопрос наличия свободного времени.
Это все от производителя зависит. У "облачных" решений есть определенный уровень удобства - ничего не нужно настраивать, включил - работает.
Вот, например, на моем GPON-модеме явно есть проблема с маршрутизацией между подсетями (LAN, WiFi, 5G WiFi). Если бы мобильное приложение ломилось напрямую к ПК, то скорее всего оно бы не работало. Вот здесь разработчики Вашего девайса этот головняк пофиксили в корне :)
Что до конкретно этого случая, то нужно либо искать, либо писать мобильное приложение или веб-приложение, которое будет напрямую общаться с ПК. Почему этой опции у этих китайских разработчиков нет "из коробки" - вопрос риторический.
На малине кажется 4 USB, можно купить 4 внешних звуковушки (по 300 руб. каждая) - получается 4 микрофона можно подключить, ну а еще есть USB-разветвители :)
Desktop-приложение выполняется непосредственное в ОС пользователя. То есть нужен исполняемый файл, который будет запускаться в ОС. Пользователь запускает файл, открывается графический интерфейс, через него пользователь выполняет какие-то действия.
Начать нужно с проекта - что с чем соединить, какую логику заложить. Модули будут зависеть от этого, от выбранной схемы питания, от логики и задачи.
Здесь все же не проектное бюро, чтобы подобные вещи делать. А решать этот вопрос я бы начал с готовых примеров, аналогов. С того, что люди уже делали - Ваши задумки не уникальны.
Так что дельный совет - идти на специализированные форумы по ардуино/электронике и там искать по ключевым словам решения, которыми поделились участники.
Наиболее подходящее решение нужно адаптировать под свою задачу, тут уже можно и о модулях поговорить.
Если нет особенных требований к питанию, то Ardunino Nano тоже подойдет.
Если будете покупать Bluetooth-модуль, то правильный нужно выбрать, с хорошей прошивкой, которая сможет передавать нужные параметры, что-то типа HM-10 и JDY-08. У первого очень много подделок, которые не умеют и 10% от оригинальной прошивки.
Учтите расстояние, для Bluetooth больше чем на 20 метров рассчитывать не стоит.
У меня был случай более тяжелый - Dynamics CRM. Там каждую неделю меняется очень сильно структура и нет никаких ИД для привязки вообще, потому что этим заведуют разработчики Microsoft и им плевать на всех остальных :)
В итоге встал вопрос о целесообразности автоматизации тестирования. Руками было проще протестить, чем поддерживать автотесты. Ну это так, к слову.
Еще подумался вариант: не разрывать оценку отдельно по разработке и по автотестированию. Если оценивается история, то у в оценку нужно заложить как разработку, так и актуализацию автотестов. Тогда каждая новая история, которая будет ломать все, будет "стоить" аналитику целый спринт и он задумается об эффективности в первую очередь.
Давай уже тогда исходники и с ардуинки, чтобы еще два дня не биться.