Как я проектирую ИИ для теплицы: почему начинаю не с модели, а с данных
У меня есть личный инженерный проект, который я долго вынашивал и наконец довёл до детальной спецификации: система автоматизации закрытой теплицы для зелени и рассады. Сразу честно про стадию — железо ещё не собрано. Но это уже не «идея в голове»: я выбрал конкретные компоненты и свёл спецификацию. То есть проект на бумаге, но бумага очень подробная.
Обычно про такое пишут, когда всё уже собрано и мигает светодиодами. Я решил написать раньше — на этапе проекта. Когда формулируешь замысел словами, дыры видно сразу. Плюс мне интересна обратная связь до того, как я потрачу месяцы. И я привык строить в открытую — показывать не только результат, но и то, как принимаются решения.
Эта статья — в основном про то, как я думаю об ИИ-части. И главный вывод у меня получился непопулярный: начинать надо не с нейросети, а с данных. А до данных — с честного вопроса, где ИИ вообще нужен.
Где в теплице нужен ИИ, а где нет
Первое, что важно признать: большая часть автоматизации теплицы — это вообще не ИИ. Это простые правила.
Температура выше порога — открыть форточку. Влажность грунта ниже порога — включить полив. Свет по расписанию. Всё это решается обычной логикой на контроллере, без единой строчки машинного обучения. И это правильно: если задачу закрывает if temp > 26: open_vent(), тащить туда нейросеть — инженерная ошибка и лишний источник отказов.
Поэтому первый слой системы я проектирую как честную реактивную автоматику на правилах: датчики, пороги, реле. Надёжно и чинится за минуту.
ИИ я вижу ровно в двух местах, где правила упираются в потолок:
1. Глаз агронома. Ни один датчик влажности не заметит пятно на листе, дефицит, начало болезни или стресс. Это видит человек глазами при обходе. Компьютерное зрение здесь — прямая замена этого обхода. Для меня это самая ценная часть, поэтому камеры в спецификации стоят изначально.
2. Упреждение вместо реакции. Правило реагирует постфактум: температура уже подскочила. А микроклимат инерционный, и хочется управлять на опережение — предсказать перегрев заранее. Это задача по временным рядам, и правилами она не берётся.
И там, и там ИИ бесполезен без одного — без данных. Поэтому первый настоящий этап проекта — не модель, а сбор датасета.
Мой подход к ИИ-части: сначала готовые модели, потом свои данные
Я не собираюсь на старте обучать нейросеть с нуля — это не имеет смысла, пока нет своих данных. План другой, и он приземлённый.
Контур диагностики, который я закладываю:
Камера → фото каждые 12 часов
→ vision-модель через API → диагноз (дефицит / болезнь / стресс)
→ команда на Raspberry Pi
→ точечное действие: клапан или дозатор нужного растения
→ отчёт в Telegram с фото «до / после»Ключевая идея — поклапанная адресность. У меня на каждое растение свой электроклапан и своя капельница, а дозирующие насосы могут менять раствор. Значит, диагноз по камере превращается не в абстрактный алерт, а в конкретное действие для конкретного растения: увидели дефицит на растении №7 — скорректировали именно его питание, а через 12 часов сравнили фото. Именно ради этой адресности в проекте столько клапанов и камер.
На старте «модель» — это готовая vision-модель через API (я в своих продуктах уже плотно работаю с AI-API, так что это знакомый инструмент). Своё обучение приходит позже — когда накопится размеченный датасет из моих реальных условий. И вот почему это важнее самой модели.
Почему данные, а не модель
Соблазн начать с интересного: взять готовую нейросеть, скормить фото листа, получить «здоров/болен». Но чужая модель, обученная на идеальных студийных снимках, спотыкается о мою реальную теплицу: другое освещение, ракурс камеры, конкретные сорта, пыль на объективе.
Значит, ценность не в самой модели — их сейчас много и они доступны, — а в своих размеченных данных из моих условий. Это и есть настоящий актив проекта. Отсюда следствие, которое переворачивает порядок работ: сбор данных должен идти с первого дня, ещё когда система крутится на голых правилах и готовой vision-модели через API.
Что я планирую собирать:
- Телеметрию датчиков как временные ряды: температура и влажность воздуха, влажность грунта по каждому растению, CO₂, освещённость, состояние раствора.
- Кадры с камер по расписанию — визуальный ряд, как растения меняются день ото дня.
- Действия системы — когда что сработало (полив, проветривание, дозирование). Без этого не связать причину и следствие.
- Результат — состояние растений, замеченные проблемы. Самая труднодобываемая, но самая ценная часть разметки.
Тут вылезает честная проблема холодного старта: нет данных → нет своей модели, но чтобы собрать данные, система уже должна работать. Обхожу прагматично: сначала польза на правилах + готовая vision-модель, параллельно с первого дня копятся телеметрия и кадры, разметка по мере накопления, и только потом — дообучение на собранном.
Железо: что конкретно я выбрал
Раз данные и адресность в центре, вот спецификация, к которой я пришёл.
- Raspberry Pi 4 — сбор данных, хранение, обработка кадров, локальная логика.
- ESP32 — отдельный узел под массив датчиков влажности грунта (по датчику на растение).
- DHT22 — температура и влажность воздуха.
- MH-Z19B — CO₂.
- Ёмкостные датчики влажности грунта — на каждое растение отдельно.
- pH-метр и TDS/EC-метр — состояние питательного раствора.
- HC-SR04 — уровень воды в баке.
- BH1750 — освещённость.
- DS18B20 — температура по зонам.
- Бак, погружной насос.
- Электроклапан + регулируемая капельница на каждое растение — то самое поклапанное управление.
- Перистальтические насосы для питательного раствора (компоненты A/B), коррекции pH и профилактических добавок — из баков концентрата.
- LED-панели, управление через реле, программируемое расписание.
- Вытяжной вентилятор с угольным фильтром, регулятор скорости через ШИМ, пассивный приток, осциллятор для обдува.
- Pi Camera v3 — под vision-анализ растений.
- Отдельные камеры видеонаблюдения — контроль 24/7.
- Raspberry Pi как хаб + сценарии автоматизации.
- vision-модель через API — анализ фото каждые 12 часов.
- Telegram-бот — управление и алерты.
- WireGuard VPN на Pi + DuckDNS — удалённый доступ к системе.
Почему я вообще за это взялся
Пятнадцать лет я работал в бизнесе, в основном в агросекторе — и достаточно повидал, как решения на земле принимаются «на глаз». Потом ушёл в разработку, самостоятельно освоил инструменты и сейчас строю AI-продукты; основной мой проект — Primerka, платформа виртуальной примерки одежды. Теплица — место, где сходятся два моих интереса: агро, которое я знаю изнутри, и разработка с ИИ, которой занимаюсь сейчас.
И именно агро-опыт держит меня в трезвости насчёт ИИ. Я видел достаточно красивых презентаций, которые разбивались о реальное поле. Поэтому план нарочито приземлённый: сначала польза на простых правилах и готовой модели, потом честный сбор данных, и только потом — своё обучение на том, что собрано в моих условиях.
Если вы делали похожее — по сбору телеметрии, поклапанному поливу, разметке визуальных датасетов в «полевых» условиях, — мне интересен ваш опыт и грабли. Буду писать по мере продвижения: следующий пост — когда соберу первый узел и пойдёт реальная телеметрия.
Курмет Жолдыбаев, Костанай. Основатель Primerka. Больше о проектах — на kurmetzholdybaev.kz, связаться — в LinkedIn.