Инженерная задача
Разработать и проверить продукт, пока физический контроллер и интеграция датчиков ещё менялись.
Habion
- Фокус
- Full-stack / IoT
- Год
- 2026
- Стек
- Next.js · TypeScript · Go · PostgreSQL · RTK Query · IoT Simulation
Моя роль
Product / Full-stack Engineer. Я работал с фронтендом на Next.js, основой бэкенда на Go, моделью телеметрии, симулятором и сценариями взаимодействия с устройством.
Архитектура
Симулятор / контроллер → сервисы Go → PostgreSQL → состояние API → Next.js + RTK Query → панель, оповещения и команды
Результат
Рабочий MVP, фронтенд и бэкенд которого можно было проверять на реалистичной телеметрии и сценариях отказа, не дожидаясь финального оборудования.
Habion — ранний продукт для автоматизированного полива, объединяющий веб-панель, API телеметрии и команд, историю измерений, оповещения и компактный локальный интерфейс контроллера. Главная инженерная задача была в последовательности разработки: программную часть нужно было сделать тестируемой раньше, чем завершится интеграция финального оборудования.
Разработка до готовности устройства
Панели нужны не только штатные показания датчиков. Система полива должна представлять давление и расход, активные зоны, команды, оповещения, состояние соединения и сбои — например аномальные показания или возможную утечку. Эти состояния стали контрактом между поведением устройства, логикой бэкенда и веб-приложением.
Я сделал симулятор телеметрии, имитирующий ESP32-контроллер и генерирующий реалистичные измерения и сценарии отказа. Благодаря этому состояния интерфейса, оповещения, исторические данные и команды можно было разрабатывать и тестировать до готовности интеграции финального контроллера.
Бэкенд и модель телеметрии
Бэкенд строился вокруг приёма телеметрии, истории измерений, оповещений и команд: Go отвечает за сервисный слой, PostgreSQL — за постоянное хранение состояния. Веб-клиент работает с этой моделью и не зависит напрямую от деталей конкретного датчика или протокола контроллера.
Такое разделение позволяет независимо развивать обе стороны: интеграция с оборудованием может меняться, а продукт сохраняет стабильное представление зон, измерений, состояния соединения, тестов и команд. Симулятор и физическое устройство при этом проходят через одни и те же продуктовые сценарии.
Локальный интерфейс на тех же состояниях системы
Контроллер должен оставаться полезным без веб-панели, поэтому компактный OLED-интерфейс показывает те же основные зоны, телеметрию и состояния через гораздо более ограниченный набор действий.
Изображение корпуса пока остаётся концептуальным макетом; сам локальный интерфейс был реализован и протестирован на микроконтроллере.
Одна модель для веб-интерфейса и устройства
Фронтенд на Next.js/React использует переиспользуемые компоненты статуса, графиков, зон и оповещений поверх RTK Query. Одна доменная модель обслуживает и удалённую веб-панель, и сокращённый набор состояний локального интерфейса контроллера.
Кейс показывает подход, особенно полезный в продуктах, связанных с железом: заранее определить предметную область и интерфейсы, симулировать отсутствующий физический слой и развивать фронтенд, бэкенд и интеграцию с устройством параллельно, а не строго друг за другом.