MQTT для автополива должен быть понятным через месяц после запуска. Если топики названы случайно, автоматизация быстро становится хрупкой: непонятно, где состояние датчика, где команда насоса, где availability, а где журнал событий. Хорошая структура топиков делает систему читаемой для GrowerHub, Home Assistant, Node-RED и человека.
Проектировать лучше от зон. Не "датчик 1", а зона, роль и параметр. Например: теплица слева, влажность почвы, состояние насоса, протечка, команда полива. Тогда замена устройства не ломает смысл данных.
Состояния
Состояния датчиков должны публиковаться отдельно от команд. Для влажности почвы, температуры, влажности воздуха и протечки нужны понятные payload и единицы измерения. Если датчик отправляет JSON, сохраняйте стабильные поля: value, unit, battery, updated_at или аналогичную структуру.
Для Home Assistant важно, чтобы entity получала состояние из предсказуемого state_topic. Если используется MQTT discovery, конфигурация должна указывать правильные топики, уникальные идентификаторы и device metadata. Подробности есть в статье MQTT discovery Home Assistant.
Команды
Команда насоса не должна быть тем же топиком, что и состояние. Иначе легко получить петлю или неверную интерпретацию. Разделяйте command и state. Команда может быть "start", "stop" или заданная длительность, но контроллер все равно должен проверять лимиты локально.
Для критичных устройств полезно публиковать подтверждение: команда принята, насос включен, насос выключен, остановлен по лимиту. GrowerHub должен видеть не только намерение включить насос, но и фактическое событие.
Availability
Отдельный слой - доступность. Если датчик влажности давно не обновлялся, автоматическое правило полива не должно считать старое значение свежим. Availability можно получать от Zigbee2MQTT, ESPHome, собственного контроллера или рассчитывать по времени последнего сообщения.
Для Home Assistant MQTT sensor есть параметр истечения состояния, который переводит сенсор в unavailable после отсутствия обновлений. В GrowerHub тот же принцип нужен для безопасности: нет свежих данных - нет рискованного автоматического полива.
События и журнал
События отличаются от состояний. Полив выполнен, лимит сработал, сервисный режим включен, протечка заблокировала насос, оператор запустил вручную. Эти сообщения нужны для истории и отчетов. Они не должны перезаписывать текущее состояние датчика.
Журнал событий особенно важен при интеграции с Node-RED. Поток может принять решение, но GrowerHub должен записать, почему оно произошло. Сценарии Node-RED разобраны в статье Node-RED сценарии полива.
Вывод
Для MQTT-автополива нужны отдельные топики для состояний, команд, availability и событий. Структурируйте их по зонам, не смешивайте команду и состояние, проверяйте свежесть данных и фиксируйте результат действия. Тогда MQTT остается инфраструктурой, а не источником путаницы.