Утром собирались поливать, а телефон обещает дождь. Подождать или включить воду? Такой вопрос можно передать контроллеру, если заранее определить, сколько воды осталось у корней и как долго допустимо ждать. Прогноз даст повод пересмотреть план, а местные наблюдения помогут принять решение.
В этом учебном проекте разберём логику для развития базового автополива на ESP32. Схемы и JSON помогут спланировать поведение; подключение погодного сервиса и исполнительного узла предстоит реализовать и испытать на своей установке.
Осматриваем то, что уже собрано
- ESP32 и датчик, показания которого проверены на вашем грунте или субстрате.
- Исполнительный модуль, подходящий насосу или клапану, питание с учётом пускового тока, защита проводки и корпуса.
- Контроль наличия воды и, при необходимости, расхода или давления. Положение реле само по себе не подтверждает подачу воды.
- Надёжное время для проверки прогноза, связь с сервером и журнал событий. Локальные ограничения должны работать и при потере связи.
Начните с имеющейся установки. Насос на 12 В может остаться в проекте: сама погодная поправка другого напряжения не требует. Проверьте питание, коммутацию, датчики и защиты, затем составьте список доработок вместе со связью, сервером и обслуживанием.
Разбираемся с числами от почвенного датчика
Посмотрите на единицы своего датчика. У простого ёмкостного щупа проценты часто показывают условную шкалу между выбранными точками. Для объёмной влажности VWC нужны соответствующая калибровка и проверка условий. Подбирайте порог под свою почву, культуру и фазу развития, сохраняя различие между этими шкалами.
В материале Университета Миннесоты решение связывается с запасом воды в корневой зоне, полевой влагоёмкостью и допустимым истощением запаса. Эти понятия отличаются от показания одного датчика. Для настройки важны также глубина корней, размещение датчиков, неоднородность участка и возможности поливной системы.
Песчаная почва, суглинок и глина требуют своей настройки, но универсальные множители времени полива для них не подходят. Один и тот же объём может по-разному распределяться, стекать или уходить ниже корней. Начните с выбора и установки датчиков, затем сравните измерения с состоянием корнеобитаемого слоя.
Даём прогнозу ограниченное время на ожидание
Сначала оцените текущий запас и допустимый срок ожидания. Если вода уже нужна по правилам вашей зоны, сохраните полив в плане. Если запас позволяет, назначьте отсрочку с конкретным сроком повторной проверки. Так обещанный дождь превращается в проверяемое решение.
Сопоставьте три записи: вероятность дождя, ожидаемые миллиметры и фактическое пополнение у корней. После осадков вернитесь к дождемеру и датчикам почвы. Это поможет увидеть, какая часть прошедшего дождя действительно изменила запас воды.
Метод водного баланса UMN учитывает поступление воды, её расход и потери. Прогноз помогает планировать, но расчёт сверяют с наблюдениями. Увеличивать длительность только потому, что температура превысила одну границу, тоже неправильно: FAO описывает влияние культуры и климатических условий на эвапотранспирацию. Наружная температура не является готовой нормой полива.
Учитываем, что над грядкой: небо или покрытие
| Условия | Что учитывать | Чего не делать автоматически |
|---|---|---|
| Открытое поле | Измерения почвы, возможный дождь, допустимость ожидания | Отменять полив только по сумме осадков в прогнозе |
| Закрытое непроницаемое покрытие | Измерения внутри и отсутствие прямого поступления наружного дождя | Засчитывать наружный дождь как внесённую воду |
| Открываемый тоннель | Фактическое положение покрытия и возможное попадание осадков | Считать режим постоянным независимо от положения покрытия |
У теплицы свой микроклимат. Прогноз снаружи сопоставляйте с температурой и влажностью внутри, состоянием вентиляции и почвой. Каждый показатель отвечает на свой вопрос: высокую влажность воздуха и открытие форточки рассматривайте отдельно от запаса воды у корней.
Отмечайте конденсат и состояние растений в журнале. Режимы утра, дня и вечера подберите под культуру, субстрат и установку. Наблюдения помогут выбрать изменения режима, а для определения причины болезни потребуется отдельная проверка.
Передаём прогноз в понятном формате
Поставьте между погодным сервисом и ESP32 небольшой прокси на Raspberry Pi или другом сервере. Там удобно хранить ключ и приводить ответы к одному формату. Настройте кэш с учётом лимитов сервиса и сохраняйте возраст прогноза, чтобы повторная выдача оставалась узнаваемой.
Ниже учебное сообщение для условной зоны example-zone. Это пример формата, который предстоит заполнить данными своего провайдера. Интервалы идут с 06:00 до 18:00 UTC без правого конца; в вымышленных данных сумма осадков — 0,8 мм, максимум температуры — 31 °C. Попробуйте проследить, как такой ряд будет разбирать программа.
{
"location_id": "example-zone",
"provider": "example-not-real-provider",
"provider_issued_at": null,
"received_at": "2026-09-27T06:00:00Z",
"valid_from": "2026-09-27T06:00:00Z",
"valid_to": "2026-09-27T18:00:00Z",
"interval_seconds": 3600,
"precipitation_mm_hourly": [
0,
0,
0.2,
0.6,
0,
0,
0,
0,
0,
0,
0,
0
],
"air_temperature_c_hourly": [
20,
22,
25,
27,
29,
30,
31,
30,
28,
26,
24,
22
],
"rain_probability_pct": null
}Время получения received_at не подменяет время выпуска прогноза. Здесь provider_issued_at неизвестно, поэтому null; отсутствие вероятности дождя тоже обозначено null, а не нулём. В рабочем адаптере определите, какие сведения провайдер действительно выдаёт и при каких ограничениях свежести их разрешено использовать.
Проверьте зону, единицы, интервалы, количество значений, пропуски и допустимые типы. Значение null, ошибка API или неполный ряд — не «дождя не будет». При неверном времени или просроченном ответе погодная поправка не применяется. Канал обмена должен проверять источник и целостность данных; ключи не передаются в открытом виде и не выводятся в журналы.
Разбираем решение по состояниям
Пройдите следующий алгоритм как настольный опыт. Это описание состояний: задайте для своей зоны пороги, предельную отсрочку, объём и паузу после полива, затем проверьте переходы до подключения автоматики.
1. Проверить локальные защиты, исправность и свежесть измерений.
2. При отказе выполнить настроенный безопасный переход и выдать событие.
Не считать неисправный датчик показанием «сухо» или «влажно».
3. Определить потребность и допустимость ожидания по настройкам зоны.
4. Проверить режим покрытия и пригодность прогноза.
5. Если прогноз непригоден, перейти к проверенной локальной логике
без погодной поправки; сохранить локальные ограничения.
6. Если ожидание допустимо и прогноз обосновывает его, назначить
конечный срок повторной оценки. Не продлевать ожидание бесконечно.
7. Иначе рассчитать допустимый объём и передать ограниченную команду.
8. Во время подачи контролировать исполнительный узел и ограничения.
9. По завершении записать подтверждённый результат или его отсутствие.
10. После проверенной для участка паузы повторно оценить состояние.У каждой отсрочки запишите причину и срок. При новом измерении, изменении прогноза или покрытия пересмотрите решение; по достижении срока вернитесь к проверке. Отдельно попробуйте повтор одного сообщения: он должен сохранять прежнее решение, не запуская помпу заново и не продлевая ожидание.
Потеря сети сама по себе не означает отказ датчика или запрет любого полива. Но переход к локальному режиму допустим только при заранее проверенной логике и исправных необходимых входах. Если такой режим ещё не подготовлен, система должна явно сообщить о необходимости ручного решения.
Сопоставляем команду с реально поданной водой
Измерьте расход при рабочих условиях и по нему переводите выбранный объём во время. Проверьте распределение воды у растений, фильтры и давление. Тогда длительность в программе будет связана с понятным результатом на участке.
время подачи = заданный объём / проверенный расход
Эта связь применима только при согласованных единицах
и подходящих условиях измерения расхода.
Команда «помпа включена» не является измерением объёма.После полива понаблюдайте, через какое время реагирует датчик. По этим наблюдениям выберите паузу перед повторной оценкой. Если отклика нет, проверьте задержку движения воды, контакт, исправность, запас в ёмкости и равномерность подачи, прежде чем назначать ещё один цикл.
Задайте пределы одного цикла и суммарной подачи за выбранный период, минимальный интервал и правила восстановления после перезапуска. Проверяйте наличие воды, сухой ход, отсутствие ожидаемого потока и неожиданный поток при выключенной команде, если установлены соответствующие датчики. Одна программная переменная не заменяет независимую защиту исполнительного узла.
Получение прогноза не должно задерживать остановку помпы. Отделите сетевые операции от критичных проверок и испытайте задержки, зависание связи и перезапуск. Уведомление сообщает о проблеме, но не должно быть единственным действием при отказе.
Первый опыт с погодной поправкой
- Проверьте базовый локальный полив, датчики, ограничения и ручное управление.
- Сначала записывайте предложения погодного алгоритма без передачи команд.
- Сравните предложения с измерениями, фактическими осадками и наблюдениями на участке.
- Разрешайте автоматические изменения только в проверенных пределах; оставьте понятный способ отключить погодную поправку.
- Испытайте просроченный прогноз, пропуски данных, неверную зону, отсутствие дождя вопреки прогнозу, отказ датчика, пустой бак и повтор сообщения.
В журнале и панели показывайте единицы, покрытие, возраст измерений и причину решения. Так будет видно, почему контроллер предлагает ждать или поливать. Фотографии ESP32-CAM добавят контекст о растениях; подбор коэффициентов и оценку воды выполняйте по данным своей зоны.
Сначала сравните предложения алгоритма со своими решениями. Записывайте поданную воду и состояние культуры, возвращайтесь к случаям, когда прогноз ошибся. Такой журнал поможет довести правила до подключения автоматического управления.
