Технически проект нельзя назвать особенно сложным. ESP32 отправляет HTTP-запросы, Go принимает их, SQLite хранит данные, а Web Push сообщает о проблемах.

Небольшие проекты позволяют ошибаться с архитектурой и пробовать новое без недель согласований. У меня таких экспериментов получилось несколько.

Не строить систему на тысячу устройств ради одного Сначала в проекте был PostgreSQL. Вполне нормальный выбор. Можно было добавить Redis, очереди и подготовиться к тысячам устройств. Оставалась одна проблема: у меня было одно устройство.

В какой-то момент я перестал спрашивать «как построить идеальную систему?» и спросил «что нужно прямо сейчас?».

Ответ: одна ESP32, один VPS, Go backend и SQLite.

Если устройств когда-нибудь станет тысяча — это будет хорошая проблема. Тогда её и решим.

Железо имеет право испортить архитектуру Я выбрал Ethernet, написал код, продумал подключение — и столкнулся с неработающим модулем. Можно было заказать другой, снова проверять SPI и упорно спасать первоначальный план. Но стоило вернуться к вопросу: мне нужен именно Ethernet или возможность узнать, выходит ли офис в интернет? Встроенный Wi-Fi решал задачу уже сейчас. Бракованный Ethernet-модуль неожиданно стал хорошим архитектурным ревьюером.

Иногда лучше не заходить в сеть вообще Можно было получить белый IP, открыть порты и проверять офис извне. Я выбрал обратную схему: офис сам обращается к внешнему серверу. ESP32 инициирует исходящие HTTP-запросы. Не нужно пробрасывать порты, настраивать NAT или выставлять устройство в интернет. Для моей задачи этого оказалось достаточно.

Simulator оказался важнее, чем ожидалось Симулятор появился по прозаичной причине: железо ещё не приехало, а программировать уже хотелось. Я написал виртуальное устройство и начал разрабатывать backend. Позже симулятор позволил проверять регистрацию, heartbeat, потерю связи, инциденты и восстановление без перепрошивки ESP32. Настоящая плата нужна, когда проверяется именно поведение железа. А серверный протокол можно тестировать отдельно.

Этот подход я точно заберу в следующие IoT-проекты. Особенно если железо снова будет ехать дольше, чем пишется backend.

Heartbeat интереснее, чем кажется Сначала всё выглядело как один HTTP endpoint: получил heartbeat — устройство работает. Но что, если запрос не пришёл? Сколько ждать? Когда объявлять OFFLINE? Как не создать десятки одинаковых инцидентов? Когда считать связь восстановленной?

Так вокруг простого запроса появились threshold, incident lifecycle, recovery policy и уведомления. Сам endpoint оказался самой неинтересной частью. Сложность — в определении состояния системы по неполному и нестабильному сигналу. И не только в IoT.

Pet-проект как полигон Я хотел познакомиться с ESP32 на реальной задаче, попрактиковаться в Go и проверить работу с coding agents. Последнее стало отдельным экспериментом. Вместо «агент, сделай уведомления» я постепенно пришёл к этапам: исследование, планирование, реализация, тестирование, review, исправления и документация. Для небольшого проекта звучит избыточно. Зато результат можно проверить не по обещанию «вроде работает», а по реальному поведению устройства. Heartbeat либо приходит, либо нет. Инцидент либо открывается, либо нет. Push либо доставляется, либо нет. Этот опыт пригодится и дальше.

Иногда нужно просто остановиться Сюда ещё можно добавить графики, latency, packet loss, OTA, настройку Wi-Fi через Web UI, Prometheus, Grafana, несколько probe и даже собственную плату с корпусом. Почти каждое улучшение можно обосновать. Но исходная задача уже решена. ESP32 стоит в офисе и сама выходит в интернет. Backend отслеживает потерю связи. Web UI показывает состояние. Уведомления сообщают о проблемах. LightPulse получает периодический сигнал.

И в какой-то момент нужно перестать проектировать следующую версию и признать: Шалость удалась.

#ESP32 #IoT #GoLang #Backend #PetProject #SQLite #Мониторинг #CodingAgents #Разработка