Всё начинается довольно невинно.
У вас дома стоит растение. Его нужно поливать, но вспоминаете вы об этом либо слишком поздно, либо после того, как полили «на всякий случай» несколько дней назад. В какой-то момент вы покупаете ESP32, датчик влажности, небольшой насос, открываете несколько роликов на YouTube и понимаете: это же можно собрать за вечер.
И правда можно. Несколько проводов, немного кода: если почва сухая — включить насос. Через час на столе стоит первая система автополива, а в голове появляется приятное чувство, что теперь растение под контролем.
Потом проходит неделя.
Датчик показывает странные значения. Насос шумит, но воды почему-то почти не добавляет. Wi‑Fi отключается, и непонятно: растение не полили потому, что почва влажная, потому что устройство зависло или потому, что приложение не может достучаться до платы. Затем появляется второе растение. Потом хочется видеть историю. Потом хочется открыть данные в Home Assistant. Потом оказывается, что один и тот же датчик в кокосовом субстрате и обычной земле ведёт себя совершенно по-разному.
И простой вечерний проект становится проблемой и головной болью: появляется много деталей, о которых нужно думать одновременно, а писать, проверять и поддерживать всё это в одиночку становится сложно.
Из такого ощущения появился Smart Plant OS.
Это открытый проект системы ухода за растениями. Один ESP32 ухаживает за одним растением и полностью контролирует его: получает показания датчиков, следит за водой, хранит настройки, принимает решение о поливе и управляет насосом. Веб-приложение существует с самого начала: с ним можно управлять одним растением, а затем объединить все растения в одном интерфейсе Smart Plant OS.
Идея простая: добавить второе, пятое или десятое растение не должно означать, что пора собирать отдельную коллекцию скетчей, страниц и случайных настроек.
При этом система должна быть понятной. Если пропала связь, ESP32 всё равно должен понимать, можно ли безопасно поливать растение. Если датчик неисправен или давно не передавал данные, автоматика не должна делать вид, что всё нормально. Если бак пуст, насос не должен включаться. Если команда пришла повторно из-за ошибки сети, система должна распознать её и не запускать второй полив.
На словах это кажется очевидным. Но именно из таких мелочей и складывается устройство, которому можно доверять.
Когда я начал думать о Smart Plant OS, быстро стало понятно: написать код для датчика и насоса — самая лёгкая часть. Гораздо труднее заранее договориться, что именно система считает ошибкой, что она обязана сохранить после перезагрузки, какие данные показывать пользователю и как не превратить красивый интерфейс в источник опасных команд.
Поэтому проект начался с архитектуры и документации.
Сейчас в репозитории есть HTML-прототип интерфейса с демонстрационными данными. Он показывает, каким может быть приложение, но не управляет настоящим насосом и не пытается выглядеть готовым устройством. Зато уже описаны правила полива, форматы данных, события, ошибки, настройки, API-контракт и будущие интеграции.
Например, «влажность почвы» не выдаётся за абсолютную истину. Датчик сначала отдаёт сырое значение, а понятный индекс появляется только после калибровки под конкретный датчик и конкретный субстрат. Объём воды, рассчитанный по времени работы насоса, называется оценкой, а не точным измерением. Неисправный датчик, пустой бак и неизвестное состояние системы должны блокировать автоматический полив.
Это может показаться чрезмерной осторожностью для одного горшка. Но без таких правил домашняя автоматика быстро становится набором догадок: «вроде работало», «кажется, там стоит порог 40», «не знаю, почему вчера включился насос».
Есть и другая причина делать проект открытым.
Закрытые устройства часто удобны, пока всё идёт по плану. У них есть готовое приложение, поддержка, аккуратный сценарий первого запуска. И производители обычно внимательно относятся к стабильности своих продуктов.
Но у владельца почти всегда остаётся меньше свободы. Он не может увидеть, как именно принимаются решения. Не может спокойно использовать другой интерфейс. Не может добавить нужную интеграцию, если её нет в планах производителя. Он зависит от того, как долго устройство будет поддерживаться, будет ли доступно приложение и останется ли нужная функция после следующего обновления.
Smart Plant OS не пытается воевать с каждым готовым устройством на рынке. И не утверждает, что open source сам по себе лучше любого коммерческого продукта. Идея в другом: система для дома и растений должна быть доступна для понимания и развития тем людям, которые ей пользуются.
Если хочется поменять интерфейс — это возможно. Если хочется добавить Home Assistant — система должна быть к этому готова. Если нужна история на NAS или microSD — это не должно ломать базовую работу. Если кто-то нашёл ошибку или придумал лучшее правило — он может принести идею в общий проект.
И здесь появляется вайб-кодинг.
Несколько лет назад участие в таком проекте для многих начиналось с барьера: нужно знать язык программирования, устройство ESP32, работу с сетью, интерфейсами, датчиками, документацией и Git. Сейчас можно прийти с идеей, описать её ИИ, получить первый прототип, разобраться в нём и показать другим.
Это не отменяет инженерную работу. ИИ не проверит, выдержит ли питание запуск насоса. Не заметит, что датчик подключён неправильно. Не увидит залитое растение и не возьмёт на себя ответственность за ошибку. Но он помогает быстрее пройти путь от «я хочу поучаствовать» до конкретного результата: экрана интерфейса, проверки данных, примера API, тестового сценария, описания проблемы или первого наброска кода.
Именно поэтому мне нравится идея открытого проекта в эпоху вайб-кодинга. Он может стать не только местом, где опытные разработчики выкладывают код, а пространством, куда люди приходят учиться делать настоящие продукты вместе.
Кто-то увидит в документации непонятное место и перепишет его. Кто-то предложит сценарий, в котором автоматика должна остановиться. Кто-то соберёт прототип на своём железе и поделится измерениями. Кто-то сделает интерфейс понятнее. Кто-то с помощью ИИ подготовит изменение, которое затем пройдёт ревью и станет частью проекта.
Необязательно в одиночку писать всю Smart Plant OS. Достаточно захотеть сделать её немного лучше.
Сейчас как раз тот момент, когда можно влиять на основу. Интерфейс уже есть, архитектура и спецификация подготовлены, но прошивка ещё не успела превратить все ранние решения в неподвижный старый код. Можно обсуждать, спорить, предлагать и строить систему вместе.
Я хочу, чтобы в итоге получилось приложение, где человек видит все свои растения в одном месте, понимает их состояние и не зависит от непрозрачной логики. Чтобы каждый ESP32 заботился о конкретном растении, а вся система оставалась понятной, расширяемой и локальной.
Smart Plant OS пока только начинает путь. Но, возможно, именно это и делает момент интересным: присоединиться можно не к готовому продукту, где остаётся только нажать кнопку, а к проекту, в котором ещё можно повлиять на то, каким он станет.
Репозиторий: Smart Plant OS
Там уже есть архитектура, план разработки, контракт API и инструкция для участников.
Если вам хочется, чтобы умные устройства дома можно было не только купить, но и понять, изменить и развивать, присоединяйтесь.
Комментарии (62)
Coder007
22.10.2026 15:11Автор, проясни пожалуйста, что ты сейчас хочешь реализовать? Датчики для контроля владности растений, автополив, мервер, на котором будет это храниться, облако, операционку на микроконтроллеры... Честно, из статьи не понятно. Вижу что ты призываешь всех, кто что-то хочет или может, присоединиться к проекту и внести свою лепту. Но ты объясни к чему именно присоединяться.
Из статьи вообще не понятно, с чего ты начинаешь, что хочешь использовать, как развивать и к чему это все может прийти.
Вроде какая-то логика проскальзывает, но всн так размыто, что нет ни точки начала, ни вектора, ни цели.
Я в принципе могу тебе всн от начала и до конца и рассказать и обрисовать, и разложить по полочкам, но не вижу в тпком проекте пока смысла.
Многие "псевдоразработчики", которые взяли микроконтроллер, что-то на нем сваяли, получили корявый, но результат (при помощи нейросетей) и решили что они могут такое, что просто фантастика. И начинаются потом аналогичные проекты. Берут оооочень мощный контроллер, начинают из него делать датчик влажности (что по сути избыточно), печатают корпуса, толкают туда эти платы, аккумуляторы все огромное и показывают, демонстрируют и говорят о перспективах проекта.
Итог: спустя пару месяцев, более одного датчика и небольшого MQTT сервера на своем ПК дело не доходит. И всё, идея не интересная, датчик работает криво, сервер еле пережевывает информацию, аккумуляторы садятся быстро и так далее.
Здесь как раз не только идея нужна, здесь нужна такая реализация, которая будет очень перспективная, масштабируемая, универсальная и будет иметь возможность быстрой настройки. И все желательно Plug&Play. Но такое мало кто сможет сделать без знаний электроники и программирования.
А еще, датчики необходимо делать максимально дешевыми и с минимумом мозгов. Масштабируемыми до бесконечности и на проводах.
Рекомендую тебе, если хочешь реально сделать проект, проработать основу этого проекта, сделать направления, по которым можно двигаться и задать вектора.
Одной идеи и небольшого описания - мало.
За ошибки в тексте прошу прощения, пишу с телефона.
anoldman25
22.10.2026 15:11Здесь как раз не только идея нужна, здесь нужна такая реализация, которая будет очень перспективная, масштабируемая, универсальная и будет иметь возможность быстрой настройки. И все желательно Plug&Play. Но такое мало кто сможет сделать без знаний электроники и программирования
Согласен.
А еще, датчики необходимо делать максимально дешевыми и с минимумом мозгов. Масштабируемыми до бесконечности и на проводах.
Вот здесь я не понял. Согласен, что максимально дешевыми и минимумом мозгов. Но как можно масштабировать до бесконечности и на проводах? Я не понял. Как это?
Rsa97
22.10.2026 15:11как можно масштабировать до бесконечности и на проводах?
Ну, совсем до бесконечности не надо, но, например, классический Modbus RTU/ASCII на RS-485 позволяет на два провода шины (плюс экран) посадить 247 устройств. То есть 246 простейших контроллеров, умеющих только по запросу передать текущее значение датчика (влажности, температуры, освещённости) и включить/выключить реле (полива, обогрева, лампы) могут работать от одного умного мастер-контроллера, который будет автономно выдавать команды по заданным параметрам и/или ретранслировать данные между оконечными контроллерами и mqtt-сервером . А с mqtt уже можно сопрягать систему управления, хоть HomeAssistant, хоть что-то самописное.
Coder007
22.10.2026 15:11например, классический Modbus RTU/ASCII на RS-485 позволяет на два провода шины (плюс экран) посадить 247 устройств.
Да, все верно. Но это ограничения протокола. А протокол - это программная часть, правила и условия передачи, вид пакета, последовательность байт и так далее. Это не имеет отношения к интерфейсу.
И кстати экран - здесь не важен. Передача осуществляется по 2-м проводам в полудуплексе и по 4-м проводам в полном дуплексе.
Ну, совсем до бесконечности не надо
До бесконечности, это условно.
Есть много вариантов шинной топологии и вам расскажут про rs-485, can, i2c, и вроде бы все, ничего особо другого, что в общей практике может подключаться в шину.
Все это рабочие варианты и у всех просто отличается длина линии и количество подключаемых датчиков.
А что если я скажу что даже rs-485 может иметь более 254 устройств. Мы ведь рассматриваем интерфейс, а протокол и адресация может быть пропиретарным.
Если мы возьмем Modbus RTU, то там есть ограничение по количеству узлов и оно ограничено в протоколе, поэтому мы не сможем даже обратиться к устройству с адресом больше 246.
И еще момент, когда мы говорим о том, что есть ограничение на интерфейсе или шине, то да, в рамках одного сегмента, а если ставится повторитель, разветвитель и прочее, то сегментов становится больше и каждый сегмент позволяет увеличить количество узлов кратно.
Но это касательно тех популярных шин, а что если мы делаем свою шину, на миксе между UART и SPI, то получаем последовательную шину, по принципу SPI но с настройками и инициализацией UART.
И вот эту шину можно сделать условно бесконечной. Да, пакеты байтов проходят через все узлы, но при скорости 115200, по 1 байту информации в каждый узел (и в узлы и от узлов) за одну секунду можно охватить порядка 3000 узлов. Но это не принципиально. Можно поставить и 15000 узлов и их все можно охватить, опросив всего за 5 секунд. Но куда их ставить столько. Поэтому бесконечеость здесь условная.
шина, которую я описываю - что-то типа последовательного UART но, по принципу SPI. Толкаем байты в буфер и вытаскиваем их с последнего.
То есть 246 простейших контроллеров, умеющих только по запросу передать текущее значение датчика (влажности, температуры, освещённости) и включить/выключить реле (полива, обогрева, лампы) могут работать от одного умного мастер-контроллера, который будет автономно выдавать команды по заданным параметрам и/или ретранслировать данные между оконечными контроллерами и mqtt-сервером
Все верно! Ряд небольших простых микроконтроллеров, сидящих на шине принимают команды и отрабатывают их. А мастер-контроллер (кстати в виде esp32) уже передает данные в систему умного дома, или куда необходимо.
И самое главное, нет смысла всю эту линию держать постоянно включённой. Мастер-контроллер, один раз в 10 минут включает линию (например с 134 контроллерами, которые контролируют влажность) и кидает в линию запрос влажности с каждого узла. Получает и видит, что 34 цветкам необходим полив. Соответственно этим периферийным контроллерам улетает информация о том, что нужно открыть клапаны для этих цветов и запустить центральный насос. Поливать в течение 10-15 секунд (ну или для каждого цветка можно задать время полива и закинуть это время в периферийные контроллеры) периферийные контроллеры поливают растения (открыв клапаны) и когда полив окончен, мастер-контроллер проверяет что все периферийные контроллеры отработали и просто тушит линию. До следующего времени контроля.
Таким образом еще эту систему можно сделать автономной с одним внешним аккумом (12В 7А/ч от бесперебойника)
Rsa97
22.10.2026 15:11rs-485 может иметь более 254 устройств
Не-а. Ограничение самого интерфейса. Передатчик, по стандарту, должен выдерживать 32 единицы нагрузки (unit load, UL). Минимальный приёмник (например, в MAX3485E) - это 1/8 UL. То есть, одновременно на шине может быть до 256 таких устройств. Если больше - пойдёт перегрузка передатчиков.
В остальном да, если делать что-то кастомное, то можно и больше соорудить. Но останется другая проблема, не дающая приблизиться к бесконечности, - время. Скажем, система опрашивается раз в 10 минут. На опрос датчика и передачу ему команды уходит, пусть, 1/10 секунды. То есть больше 6000 устройств за это время всё равно не опросить.
Coder007
22.10.2026 15:11Не-а. Ограничение самого интерфейса. Передатчик, по стандарту, должен выдерживать 32 единицы нагрузки (unit load, UL). Минимальный приёмник (например, в MAX3485E) - это 1/8 UL. То есть, одновременно на шине может быть до 256 таких устройств. Если больше - пойдёт перегрузка передатчиков.
Все так, но я де же написал, на одном сегменте. Это значит, что между одним мастером на MAX3485E и слейвом на таком же чипе можно засунуть не более 255 девайсов. А теперь смотрите дальше, за 255 девайсом стоит еще один сегмент повторителя, у которого в качестве мастера (повторителя) стоит такой-же MAX3485E. И за ним - снова 255 устройств. Вот и всё. Повторитель или разветвитель и вы имеете еще ряд сегментов по 256 устройств.
На опрос датчика и передачу ему команды уходит, пусть, 1/10 секунды. То есть больше 6000 устройств за это время всё равно не опросить.
1/10 секунды на датчик - это не просто медленно, это невозможно медленно! Даже если предположить, что с каждого датчика мы считываем 8 байт и отдаем ему 8 байт (это прям настолько много, что я взял по максимуму) то будем иметь вот такие цифры опроса в секунду:
• 300 бод: время на 1 датчик — 539 мс, можно опросить — 1 датчик в секунду.
• 600 бод: время на 1 датчик — 272 мс, можно опросить — 3 датчика в секунду.
• 1200 бод: время на 1 датчик — 139 мс, можно опросить — 7 датчиков в секунду.
• 2400 бод: время на 1 датчик — 72 мс, можно опросить — 13 датчиков в секунду.
• 4800 бод: время на 1 датчик — 39 мс, можно опросить — 26 датчиков в секунду.
• 9600 бод: время на 1 датчик — 22 мс, можно опросить — 46 датчиков в секунду.
• 19200 бод: время на 1 датчик — 14 мс, можно опросить — 75 датчиков в секунду.
• 38400 бод: время на 1 датчик — 10 мс, можно опросить — 109 датчиков в секунду.
• 57600 бод: время на 1 датчик — 8 мс, можно опросить — 128 датчиков в секунду.
• 115200 бод: время на 1 датчик — 7 мс, можно опросить — 156 датчиков в секунду.
Это прям с учетом всех возможных задержек и с запасом на тупняк контроллера.
И теперь, если взять ваши условия и пересчитать на 6000 датчиков, то получится вот так:
• 2400 бод: время на 1 датчик — 72 мс. На опрос всех датчиков уйдет 432 000 мс (7 минут 12 секунд).
• 4800 бод: время на 1 датчик — 39 мс. На опрос всех датчиков уйдет 234 000 мс (3 минуты 54 секунды).
• 9600 бод: время на 1 датчик — 22 мс. На опрос всех датчиков уйдет 132 000 мс (2 минуты 12 секунд).
• 19200 бод: время на 1 датчик — 14 мс. На опрос всех датчиков уйдет 84 000 мс (1 минута 24 секунды).
• 38400 бод: время на 1 датчик — 10 мс. На опрос всех датчиков уйдет 60 000 мс (1 минута 0 секунд).
• 57600 бод: время на 1 датчик — 8 мс. На опрос всех датчиков уйдет 48 000 мс (48 секунд).
• 115200 бод: время на 1 датчик — 7 мс. На опрос всех датчиков уйдет 42 000 мс (42 секунды).
Даже при самых низких скоростях (что прям редко делают) мы укладываемся в 10 минут для 6000 датчиков на rs-485.
Честно сказать, я не люблю считать грубо-приблизительно или тыкать пальцем в небо, поэтому считаю все более четко. Беру с запасом, с погрешностью, но это точнее чем просто из ниоткуда.
Ваши расчеты прям ну ооооочень странные и жесткие для обмена данными. Ну да ладно, у вас есть информация, вы сможете посчитать.
А если посмотреть мой комментарий, то не предлагал использование интерфейса rs-485, а просто описал, что там возможно сделать более 256 устройств. Я же описал свой интерфейс и это не то, о чем вы думаете. Давайте исходить из реальности, которую я описал.
У меня этот интерфейс реализован и работает и я представил свои цифры.
шина, которую я описываю - что-то типа последовательного UART но, по принципу SPI. Толкаем байты в буфер и вытаскиваем их с последнего.
Она не является аналогом rs-485 и работает по другому принципу.
Coder007
22.10.2026 15:11Вот здесь я не понял. Согласен, что максимально дешевыми и минимумом мозгов. Но как можно масштабировать до бесконечности и на проводах? Я не понял. Как это?
Посмотрите ниже по логике или выше по тексту, я написал комментарий. Там подробно расписано.
Могу здесь написать, но будет дублирование, а там еще и с дополнениями.
anoldman25
22.10.2026 15:11Спасибо. Честно говоря, мне провода тянуть не очень хочется, у меня цветы на разных подоконниках. Я тоже думал про цветы. Но с точки зрения беспроводной связи. Я думаю подсоединить по zigbee. ESP32-C5 поддерживает zigbee. И есть вроде конфигурация для ESPHome. Там предусмотрена посылка данных раз в Х минут. Так что батарейки хватит надолго. Жду ESP32-C5, когда приедет из Китая. Основная проблемам, как откалибровать датчик влажности. Сопротивление померить можно, а вот перевести в проценты, чешу репу. Хотя чисто эмпирическим путем. Но жалко цветы, засохнут во время эксперимента. Да и сам датчик наверное потребляет энергию. Короче, посмотрим.
Добавил.
Хотя я вижу моторчик помпы. Видимо без проводов не обойтись. Загадка.Coder007
22.10.2026 15:11Многие хотят сделать без проводов, но потом когда заходит речь о поливе, о воде, понимают, что не каждая система может быть беспроводная, как они это видели изначально. Один цветок - можно, без проблем. Поставить и бутылку с водой и моторчик и аккумулятор побольше. А подоконник из 10 горшков? А лоджия из 50 и еще в разных комнатах.
В принципе тоже можно, но ставить на каждый горшок такую систему - не очень комфортное решение. Более логично центральный микроконтроллер, схему с насосом, баком воды (и его контролем) вынести в отдельный модуль. И вот он как раз может подключаться по беспроводной сети куда вам вздумается. А на каждый горшок поставить маленький модуль контроля влажности и клапан для полива. Соединить их гирляндой от центрального модуля.
И вот такая система - будет жить. В одном месте - один беспроводной контроллер и нужное количество модулей горшков.
maximkrosh Автор
22.10.2026 15:11Спасибо за комментарий! Хочу начать с базовой рабочей системы: ESP32, датчик влажности, контроль воды в баке, насос и веб-приложение, где видно состояние растения и можно им управлять. Одна плата отвечает за одно растение, а затем несколько таких устройств можно объединить в одном приложении.
Облако не планируется. В дальнейшем интересны интеграции с Home Assistant, NAS, хранение истории, дополнительные датчики и более удобная настройка.
Сейчас ESP32 выбрана как доступная и массовая платформа, для которой много документации, библиотек и готовых модулей. Датчики для Arduino как раз являются простыми и дешёвыми благодаря массовости, поэтому на старте логично использовать их, а не пытаться сразу разрабатывать собственное железо. ESP32 для каждого растения - это текущая архитектура первой версии. Вопрос более масштабируемой и дешёвой схемы будет решаться дальше, после реальных тестов. Рассматриваются и варианты с общим контроллером для большого количества растений ,но в данный момент упор идёт больше на прошивку и её логику. Собственные платы и Plug&Play тоже интересны, но к этому нужно приходить после рабочей основы, а не начинать с красивого корпуса и громких обещаний.
Решил заняться проектом, потому что не нашёл открытой системы с похожим видением: начать с одного растения, затем расширять систему, иметь одно понятное приложение и не зависеть от закрытой экосистемы производителя. В репозитории уже есть более конкретная архитектура и план развития, а статья была способом показать идею на ранней стадии и привлечь людей к обсуждению до того, как все решения будут приняты в одиночку. Дальше хочу показывать реальные этапы: сборку, прошивку, тесты, проблемы и решения. Если есть опыт с дешёвыми проводными датчиками или другой архитектурой, будет интересно обсудить конкретные варианты, именно за этим и хочется собирать сообщество вокруг проекта.
Coder007
22.10.2026 15:11ESP32 для каждого растения - это текущая архитектура первой версии. Вопрос более масштабируемой и дешёвой схемы будет решаться дальше, после реальных тестов.
Это бессмысленно. Представьте себе масштабы хотя бы для 50 горшков с цветами.
Тут смысл в том, что бы снизить расходы. Датчики влажности нужно вешать на одну шину и ставить им самый простой микроконтроллер (Типа attiny13)
А какие тесты вы хотите проводить? Я про архитектуру системы говорю, а не про заплатки. Если вы сейчас сделаете на esp32, как вы думаете (единственное решение) то это будет дубль уже реализованных систем. Ничего нового, ноль конкуренции, много затрат. И невозможно будет потом развивать систему, потому что архитектура изначально кривая. Просто - не значит правильно. Просто - это отчасти быстро. И все вот такие платы - призывают к тому, что вы можете сделать быстро. Так делает каждый производитель.
Вот вы выбрали esp32. Почему? Видимо потому, что есть беспроводные интерфейсы, быстро настраивать и так далее. А для проекта влажности горшка с цветами и включения полива, та-же esp8266 с меньшими характеристиками, и меньшей стоимости так-же подойдет. Но обе платы изначально будут избыточными для одного горшка. Просто подумайте, что вам необходимо: 1 пин (аналоговый) для измерения влажности (самый примитивный контактный датчик) и 1 пин для включения насоса или клапана полива. Возможно 1 пин для индикации полива (но можно совместить с насосом/клапаном) и индикация сухой почвы (но это думаю лишнее) и вот итог, 2 пина. Банальная логика. И только ради передачи данных по воздуху вы берете esp32. Избыточность бешеная, себестоимость бешеная, энергопотребление для каждого горшка бешеное.
Собственные платы и Plug&Play тоже интересны, но к этому нужно приходить после рабочей основы.
Если будете про это думать "послезавтра", на 4 итерации изделия, то просто потеряете время. Про это нужно думать сразу.
начать с одного растения, затем расширять систему, иметь одно понятное приложение и не зависеть от закрытой экосистемы производителя.
Это самый примитивный подход. Вы будете иметь понятие во все времена, только для одного растения. И ничего нового не сделаете. Потому что приложение не будет адаптировано под масштабируемую систему.
Arhammon
22.10.2026 15:111 пин (аналоговый) для измерения влажности (самый примитивный контактный датчик)
Контактный датчик - только как вспомогательная защита от перелива, контакт с почвой только емкостной, металлы, вода, соли и электричество несовместимы. В теории конечно можно редко мерять сопротивление и давать такой же ток в обратной полярности так контактный датчик еще поживет какое-то время.
А так да "аттини13" самое то. Единственное само измерение и контроллер, ПО, это наверно 20% работы и денег, остальные 80% защиты, разъемы, прокладка кабелей и трубок по феншую итп. По этому все эти умные поливы забрасываются после того как немного поигрались...
ЕСП32 единственно сработает если дорого-богато по 7 дюймовой HMIке на каждый горшок, вот это будет довольно футуристично...
Coder007
22.10.2026 15:11Единственное само измерение и контроллер, ПО, это наверно 20% работы и денег, остальные 80% защиты, разъемы, прокладка кабелей и трубок по феншую итп. По этому все эти умные поливы забрасываются после того как немного поигрались...
Тут вы полностью правы. Мало проектов (хотя о чем я, их вообще нет!) которые выросли после применения esp32 и wi-fi в качестве системы управления поливом и контроля влажности почв для домашних растений.
Если продумать все четко и сразу, сделать оценку проекта и понять стоимость, то можно реализовать интересную систему. Компактную, масштабируемую, гибкую и мобильную. Звучит круто, но в реальности такое происходит редко. Все хотят сначала быстро, а потом - а потом не наступает....
Если делать грамотно, то не потребуется много защит, герметизаций и сложных разъемов. Массовость достигается за счет гибкости и модульности.
Arhammon
22.10.2026 15:11Если делать грамотно, то не потребуется много защит, герметизаций и сложных разъемов. Массовость достигается за счет гибкости и модульности.
Да и герметизация не страшна, лаком залил платы(а их в любом случае лачить, те которые контактируют с почвой, потому что маска предназначена для защиты дорожек в обычных условиях, а не для втыкания в почву). Модульность тоже не прям страшная в электрической части, китайские разъемные терминальные блоки на 3-4 контакта рублей 30-40 комплект. Дорого только сами заказные платы, еще немного дороже с монтажем(китайцы прекрасно сами весь поверхностный монтаж сделают). А готовые модули рандомных конструкций с зоопарком разъемов соединенные дендрофекальным методом это как раз "Ардуино в негативном смысле". Про гидравлику ничего не скажу, но мне кажется если не покупать самую дешевую фурнитуру на маркеплейсах, а взять что-то промышленное оно будет как угодно соединяться, много раз и без утечек.
Coder007
22.10.2026 15:11Именно, такое решение будет и смысл иметь и продолжение, возможно и спрос при хорошей рекламе.
maximkrosh Автор
22.10.2026 15:11Согласен! Но пока рано говорить о коммерческом применении. Для меня проект интересен прежде всего возможностью максимально эффективно решить свою проблему, которая, как мне кажется, есть у многих.
Coder007
22.10.2026 15:11(а их в любом случае лачить, те которые контактируют с почвой, потому что маска предназначена для защиты дорожек в обычных условиях, а не для втыкания в почву).
Честно сказать, я думал про пару нержавеющих, сменных штырей, которые втыкаются в почву до дна. Все вот эти фокусы с платой, лаком - не самые нормальные. В итоге емкостные датчики работают, дольше, да, но конструкция один хрен монструозная. До дна не воткнуть, влажность контролим только на поверхности. Качество данных оставляет желать лучшего.
если не покупать самую дешевую фурнитуру на маркеплейсах, а взять что-то промышленное оно будет как угодно соединяться, много раз и без утечек.
Это однозначно.
Как то вот так я это вижу:
И это с тыльной стороны горшков растений.
Arhammon
22.10.2026 15:11Вот оно самое - по феншую, за соответствующую стоимость...
Нержавейка прекрасно ржавеет даже не в почве. Полюс ток через почву тащит за собой элементы, какие-то к катоду, какие-то к аноду, что приведет к тому что сопротивление со временем уплывёт куда-нибудь. Выше указывал как можно сделать, собственно делал индикатор наличия воды из медных электродов из обычного провода 2,5мм 10 лет прожили и в принципе не особо деградировали. А на постоянке сгнили бы под ноль за год. Но это опять же не тупые электроды, а полноценный датчик со своим контроллером, а если так смысла делать контактный я не вижу, ну не для экономии же на выпрямителе емкостного датчика?
Дешевые платы до 10см делают, сантиметров на 9 воткнуть можно, даже пару-тройку секции конденсатора на разных глубинах сделать...
Coder007
22.10.2026 15:11Нержавейка прекрасно ржавеет даже не в почве. Полюс ток через почву тащит за собой элементы, какие-то к катоду, какие-то к аноду, что приведет к тому что сопротивление со временем уплывёт куда-нибудь.
Да, с таким тоже сталкивался, причем у промышленных решений. Там хламина высокотоковая. У меня такие решения (датчики воды) на 1 Микроампере работают. Я не делаю схемы как все, для меня такое не подходит. Алюминий ставил, работает, пока сама не окислится, медь годами ходит, нержавейка будет вечная.
Arhammon
22.10.2026 15:11Ну если самые ранние варианты у меня были на затворе полевика поптёртого 10 МОм(а может и 20), то медь даже 330нА не переносила...
Coder007
22.10.2026 15:11Может медь такая была? Я в шахте из подручного 3х жильного кабеля датчики делал, году в 2017, в дренажном приямке, до сих пор стоят и работают. Обросли правда мусором всяким, но жилы в норме..
Arhammon
22.10.2026 15:11Может медь такая, а может вода такая... именно этот вопрос повторяемости результата закрывает емкостной метод. На емкостные датчики соленость тоже влияет в плане искажений показаний, но все равно на порядки лучше чем у контактных. Ну и если заморочаться с измерением емкости на разных частотах то практически влияет вообще.
Aleksandr_Lar
22.10.2026 15:11Прозрачные трубки осуждаю - через три дня после первой прокачки воды они будут выглядеть омерзительно из-за наросших там одноклеточных.
Трубопровод рекомендую сделать шлейфом с тройниками, один конец тройника подключить к задвижке, которая будет открываться для полива с таймером на слив воды.
Соответственно, питающий конец трубопровода подключить к водонапорной башне (нет, она не меняет воду на порно, это просто бак на 2-3 литра, расположенный на высоте около метра над подоконником) с реле-поплавком для нагнетания воды помпой и задвижкой аварийного слива (логика ((поплавок показывает снижение уровня воды) and (not (открыта хотя бы одна задвижка в горшке)) or (сработал датчик сырости на полу))).
Вдоль шлейфа пустить проводную шину последовательного интерфейса (485 какой-нибудь, прости Господи) и шину питания. На последовательный интерфейс посадить задвижки и датчики влажности со своими адресами. Датчик с электродами использовать как колышек , на который крепить задвижку с форсункой - то есть такой двузубый колышек с тройником и двумя разъёмами, сверху у него тройник и два разъёма с пинами последовательного интерфейса и питания. Логика установки - настроил адресацию, затем воткнул в землю, подсоединил трубки, подсоединил пятипроводные кабели, дальше в головном устройстве настроил таймеры и пороги по влажности (можно воткнуть дополнительную логику).
Coder007
22.10.2026 15:11Вы описали то, что я ранее написал и сгенерил нейросетью.
Тройник и клапан полива стоит внутри девайса, а не висит как попало и где попало.
Прозрачные трубки... Вы серьёзно? Я же подписал, что сгенерировал нейросетью и это даже не концепт, а модель для понимания и обсуждения.
Рукалицо.
Aleksandr_Lar
22.10.2026 15:11сгенерил нейросетью.
В этом-то и проблема. Там, где можно было бы потратить 10 минут, вооружившись ручкой и бумажкой, вы предлагаете для обсуждения эскиз, который обладает массой недостатков, помимо очевидной слопности. Признайтесь, сколько времени у вас ушло на генерацию.
Вот такое вот "рукалицо"
Coder007
22.10.2026 15:11Вам проект сделать? Могу, оплатите, по тарифу 4 тыс руб в час?
Проблема не во мне и не в генерации, а в восприятии. Вы ждете решение, а вам показывают идею. Автору этого поста нужны были идеи, варианты и прочее. Вы же зацепились к генерации картинки нейросетью. Между прочим получилось красиво и лаконично. Не ваши реле в словесном описании.
Я вижу что вы не молоды, но и я не из 2000х годов. Из Союза я, только умею развиваться и иду в ногу со временнм. И такой проект корпуса вам часа за 2 в 3D нарисую, без проблем и за пару дней и схемы и платы сделаю.
Мне пока это просто не интересно.
А на генерацию ушло минуты 3, вместе с описанием.
И это не эскиз, это генерация идеи.
И расскажите ка мне про недостатки этой и конструкции и генерации (только перед этим все мои комменты прочитайте, что бы понимать, о чем идет речь). И если хоть 10 найдете аргументированных недостатков и я с ними соглашусь, то поговорим.
А так пока кроме воздуханства, я ничего не вижу и не слышу. Критика должна быть конструктивной.
Arhammon
22.10.2026 15:11Соответственно, питающий конец трубопровода подключить к водонапорной башне
С учетом что это поливалка(с той или иной степенью дендрофекальности), а не промышленная установка мне кажется пассивно вода не должна никуда поступать, только активно снизу вверх по насосу.
Coder007
22.10.2026 15:11Да, именно насосом, это кстати позволит контролировать расход воды. Насос качает определенный объем и с определенным давлением и не зависит от уровня столба воды в водонапорной башне. Ну а воду лучше держать без доступа света и не особо греть, а это значит снизу и в прохладе. Сохранится дольше.
maximkrosh Автор
22.10.2026 15:11Опять же это удобно только для случае когда у вас все растения дома в одном месте, да и подобные промышленные решения уже присутствуют на рынке.
Coder007
22.10.2026 15:11Так кто говорит о том, что бы все в одно толкать, это же блочное решение. Есть центральный модуль, есть модули горшков.
Одни цепляются к другим, причем они взаимозаменяемые и адресные. Распределяем по группам (цветов в горшках) и устанавливаем.
Но это не промышленное решение, а домашнее и применять здесь промвшленную автоматизацию - это как на БЕЛАЗе за овощами на рынок ездить. Можно, но дорого, неудобно и продукты в кузов грузить тяжело.
А шланги их что так тянуть, что иначе. И если будет водонапорный бак (как предлагал один автоматик) то на каждую группу отдельный придется ставить. Но я бы лучше использовал емкость с насосом. Т размещал бы его внизу, подальше от света. При освещении и теплоте вода зацветает и портится быстрее.
И при наличии насоса можно поливать растения последовательно, а если поставить маленький расходомер, то еще и видеть расход воды на каждое растение. И соответственно планировать расходы и баланс воды. Аналитика и планирование. Циклы и интервалы, и автоматическое формирование карты расхода воды.
При использовании низковольтной схемы, даже с геюольшим насосом, вся эта установка будет автономно еще пару месяцев работать без внешнего питания.
Преимущества водонапорной башни - небольшие, но клапана открывать один хрен электричеством. А за 2 месяца, вода в этой башне испортится.
maximkrosh Автор
22.10.2026 15:11Спасибо, хорошее замечание. Думаю я пересмотрю архитектуру.
Моя исходная задача сейчас это квартира примерно с 5–10 растениями в разных комнатах, а не теплица или сотни горшков. В этом сценарии тянуть через квартиру общую шину связи и провода управления клапанами мне кажется безумием. Здесь беспроводная связь важна: растения можно поставить где угодно, добавить новое без прокладки кабеля и управлять всем из одного приложения. Но ты прав ESP32 на каждый горшок для измерения влажности и включения полива избыточное решение.
Скорее всего, я пересмотрю идею так: ESP32 останется главным узлом и шлюзом в веб-приложение, а для каждого растения будет отдельный очень простой и дешёвый контроллер или готовая плата с датчиками и управлением клапаном либо насосом. Вариант с проводной шиной, центральным насосом и простыми периферийными контроллерами всё равно выглядит интересно для теплицы, стеллажа или большой коллекции растений в одном месте. Возможно, со временем одна система сможет поддерживать оба сценария: беспроводные модули для квартиры и проводные сегменты для централизованного ухода.
Спасибо, что подробно расписал. Проект пока как раз на той стадии, когда такие вещи нужно переосмысливать до начала прошивки и закупки железа.
Coder007
22.10.2026 15:11Датчики для Arduino как раз являются простыми и дешёвыми благодаря массовости, поэтому на старте логично использовать их, а не пытаться сразу разрабатывать собственное железо.
Вот это кстати один из самых провальных принципов. Первое, что думает человек - это доступно и просто, а нужно думать еще о том, насколько это надёжно. Те датчики, про которые вы говорите окисляюься за пару месяцев и перестают работать. Поэтому порой лучше (для серийного образца, а желательно на него сразу делать расчет) продумать всое решение. Вам же ничего не мешает сделать 2 электрода из нержавейки и поставить туда мост и компаратор (аналогичные тому, что стоят в ардуиновском датчике) только упаковать это вместе с контроллером в компактный корпус.
Не логично использовать готовые модкли и уж тем более тратить время на изготовление корпусов для этих плат и упаковки туда всего ардуиновского.
Вот тут посмотрите проект:
Автономное устройство контроля влажности почвы (Soil Moisture Monitoring Device) https://habr.com/p/1042842/
Автор как раз делал что-то подобное и автономное. Посмотрите на монструозность проекта.
И вот статья про датчики влажности:
Давайте уже измерим влажность почвы правильно https://habr.com/p/1012024/
Eeegrek
22.10.2026 15:11Датчик влажности не особо нужен, растения прекрасно себя чувствуют при поливе их тупо по расписанию, т.к вряд ли ваши горшки стоят в каких-то постоянно изменяющихся условиях. У матери комнатные растения дома замечательно живут с такой примитивной системой автополива когда она на дачу уезжает. Раз в сутки срабатывает таймер, который включает помпу на настроенное время.
Coder007
22.10.2026 15:11Да, возможно, но датчики влажности - это как обратная связь. Ее желательно иметь. Например: неделя дождей, влажность повысилась и почва в цветах не испаряет влагу. А вы по расписанию льете туда воду, без контроля. Можно, но цветы начнут гнить. Или из поддонов начнут выливаться излишки воды.
И это еще допустимо, если цветы одинаковые, а если разные? И по разному пьют воду, с разным объемом горшков, требуют разные режимы полива.
То просто лить по расписанию - не очень подходит.
У супруги есть цветы, которые нужно поливать после высыхания почвы через 2 дня. А как узнать что почва высохла? Нужно измерить, потом отсчитать время и полить.
Некоторые цветы (цикламены) в жару любят лед и это тоже можно обеспечить в виде оповещения. Система может полить цветы, а лед может положить только человек.
maximkrosh Автор
22.10.2026 15:11Полив по расписанию действительно может быть достаточным, особенно когда условия стабильные. Но мне интересно учитывать и состояние почвы: по влажности можно подстраивать полив под конкретное растение и со временем отслеживать изменения, связанные с ростом, цветением или сезонностью.
У разных растений и субстратов разная потребность во влаге. Был опыт, когда одинаковый полив по времени одним растениям подходил, а другие либо пересыхали, либо получали слишком много воды.
sergyk2
22.10.2026 15:11этих тепличных контроллеров в интернете без меры, я начинал свой делать 20 лет назад на пике и жки экранчике. к тому времени как отладил все моменты и несколько раз переписал по, это уже стало никому не интересно.
имеет смысл делать групповой контроллер управляющий подсветкой, поливом и подогревом. вряд ли у вас будут сильно разнотипные растения, ну можно заложить задание условий для нескольких групп.
maximkrosh Автор
22.10.2026 15:11Да, именно в эту сторону и хочу развивать проект: не просто датчик с насосом, а автономную систему, которая берёт на себя полив, подсветку, подогрев и условия для нескольких групп растений.
Человек должен вмешиваться только в редкие физические вещи: долить воду, добавить удобрение, обслужить систему или пересадить растение. А конкретная реализация и состав модулей ещё будут уточняться по мере разработки.
sergyk2
22.10.2026 15:11я так кактусы выращивал из семян в автоматизированной тепличке. вот это посмотрите Источник: Народ.РУ. https://share.google/V4ocXa1Rj7qYQ3FWg
Coder007
22.10.2026 15:11Да, и каждый из горшковых узлов можно сделать полноценным контроллером зоны/участка растений, если они сидят в одном месте. Просто не attiny13 ставится а stm32f103, и все, управляй светов, вентиляцией, температуру контролируй и все, что душе угодно. Сама идея гирлянды и единого центрального узла. И таких улов скрлько угодно и модулей - тоже сколько хочешь.
Aleksandr_Lar
22.10.2026 15:11Покритикую с точки зрения промышленной автоматизации.
Я бы предложил разбить подход на "узлы автоматизации".
Самый минимальный уровень автоматизации - горшок.
Такой узел по сути состоит из двух реле:
реле времени на полив;
пороговое реле влажности.
Логика очень простая, задаётся двумя параметрами. В самом простом случае такая система также имеет свой бак с водой, для него критическим будет ещё одно реле - поплавок в баке, порог для которого задаётся один раз.
Схема работы такого устройства будет незамысловатая, причём наружу оно будет отдавать булевые сигналы:
запуск полива по таймеру;
запуск полива по влажности;
низкий уровень воды в баке;
ну и для контроля я бы добавил логику: полив произошёл, сигнал низкой влажности висит.
Такие "полевые" узлы уже можно объединить в SCADA-систему с централизованным сбором событий, а также централизованным управлением настройками. Отдельно к "скаде" уже присобачить видеокадры - схематическое изображение узлов с выводом нужной информации.
Дальше всё можно адаптировать: сделать групповое управление горшками с одинаковым режимом полива, добавить логику проверки бака (фиксировать смену воды в баке и сигнализировать "ща стухнет", добавить контроль протечки, усложнять подходы по режимам, добавить контроль инсоляции и управление досветкой, управлять вентиляцией, сделать логику управления влажностью воздуха - словом, стремиться к модели палюдариума).
Такой подход позволит отбрасывать очень много лишнего от происходящего. Но, на мой взгляд, стоит стремиться отдавать от "полевого уровня" только релейные сигналы (true/false) там, где это возможно.
maximkrosh Автор
22.10.2026 15:11Спасибо, очень понятный подход. Идея с отдельными узлами автоматизации и простой локальной логикой мне близка: на уровне горшка важно, чтобы полив и защита работали сами по себе, а центральная система в основном собирала состояние, историю и настройки.
С булевыми сигналами тоже согласен: для бака, протечки, работы полива, низкой влажности и аварий это действительно проще, надёжнее и понятнее. Более точные данные нужны только там, где они реально дают пользу. Например, для калибровки влажности или анализа изменений со временем.
Дальше такую систему действительно можно расширять группами растений, подсветкой, вентиляцией, контролем воды и более сложными сценариями. Возьму эту модель «полевой узел → централизованный сбор и управление» как ориентир при доработке архитектуры.
Coder007
22.10.2026 15:11Друдище, не стоит использовать такой подход, объясню почему:
Масштабируемость нулевая
Доработка / добавление узла - программирование всей системы, так как логика центральная, а если поставишь в каждый узел по ПЛК, то квартиру, почку и легкое придется продать.
Каждый раз перерисовывать мнемосхему при добавлении нового узла (горшка с цветком)
Много лишних компонентов, необходим ПК или HMI панель.
Сложно сделать резервирование по питанию, вернее очень дорого.
Габариты узлов больше горшков.
При централизованной архитектуре - множество проводов от модулей ввода/вывода.
Отсутствие логики (все то, что там написано - беспорядочный набор предложений)
Громоздко.
Можно еще много написать, но не буду, этого должно хватить.
И этот человек - не автоматик, он релейщик, а это разные вещи.
Coder007
22.10.2026 15:11Покритикую вас. И с точки зрения промышленной автоматизации и релейной автоматики и здравого смысла.
Такой узел по сути состоит из двух реле:
реле времени на полив;
пороговое реле влажности.
Реле времени - самое ужасное, что можно поставит на полив и каким образом оно взаимодействует с пороговым реле влажности? Кто в приоритете?
Далее, размер этих двух устройств, входное напряжение питания (стандартный блок питания на 24В, если размещать его здесь же, ну или тащить кабель и заводить 24В этим двум реле.
Как узнать состояние влажности почвы того или иного растения? Или просто поливает по таймеру и все?
Кто инициирует полив, какая владность должна быть для полива, сколько лить воды в горшок? откуда приходит сигнал, или это от реле влажности идет? Слишком много нюансов.
Логика очень простая, задаётся двумя параметрами. В самом простом случае такая система также имеет свой бак с водой, для него критическим будет ещё одно реле - поплавок в баке, порог для которого задаётся один раз.
Это логика чего? Здесь в тексте не прослеживается логика.
Какими двуия параметрами она задается, кому задается и как работает?
Вы описываете простой чан с водой, который просто поддерживает уровень. Только толкать туда поплавок - не актуально. Они как правило на герконах, большие. Для релейной автоматики пойдут, а здесь лучше сделать кондуктометрический, с микротоками и управление через микроконтроллер.
Схема работы такого устройства будет незамысловатая, причём наружу оно будет отдавать булевые сигналы:
запуск полива по таймеру;
запуск полива по влажности;
низкий уровень воды в баке;
ну и для контроля я бы добавил логику: полив произошёл, сигнал низкой влажности висит.
По какому таймеру? Уже обсуждали в этой ветке про таймер. Не для всех он подходит.
Полив по влажности, вы уже про это писали, какой уровень влажности должен быть кто принимает решение о запуске полива?
Низкий уровень воды в баке - это логика другой подсистемы и вы ее странным образом приплели сюда. Почему не добавили высокий уровень воды в баке? Тоже сигнал.
А 4 пункт - это вообще разрыв шаблона... Как после полива может быть сигнал низкой влажности? Это нонсенс! После полива влажность будеи самой высокой. Вы точно поливаете цветы, в которые воткнули датчик влажности, а не соседний огород?
Такие “полевые” узлы уже можно объединить в SCADA-систему с централизованным сбором событий, а также централизованным управлением настройками.
Вы серьёзно? SCADA систему для этого? Вы же еще ПЛК не добавили, как вы собираетесь собирать данные и управлять? Самое главное, чем управлять? Вы не написали ни одного исполнительного узла. Ни клапана, ни задвижки, ни насоса. Только датчики и те в виде реле. Так у вас не автоматищация, уроаня ПЛК, а релейная автоматика получается. Кривая, ну да ладно.
Отдельно к “скаде” уже присобачить видеокадры - схематическое изображение узлов с выводом нужной информации.
Бррррр, я даже боюсь представить ваши фантазии и их габариты! Для системы управления поливом горшков с цветами.
Здесь вы предлагаете использовать операторскую станцию для визуализации. Ну или HMI с картинкой.
Когда речь про сервер Historian зайдет, что бы хранить скудные данные этой системы и сервер MES для анализа?
Дальше всё можно адаптировать: сделать групповое управление горшками с одинаковым режимом полива, добавить логику проверки бака (фиксировать смену воды в баке и сигнализировать "ща стухнет", добавить контроль протечки, усложнять подходы по режимам, добавить контроль инсоляции и управление досветкой, управлять вентиляцией, сделать логику управления влажностью воздуха - словом, стремиться к модели палюдариума).
У вас нет ПЛК, чем вы собрались это все делать? Вы не управляете ничем, о каком групповом управлении идет речь?
Понаписали того, что не нужно, просто что бы написать?
То, что вы описывпете - я называю влажными фантазиями автоматика, который не понимает задач и целей технологического процесса, а это чревато избыточностью, перегрузом функционала и перерасходом финансов.
Такие фантазеры - это исполнители, которые думают, что если добавят всего и много в автоматизацию, то жить станет легче. А ещё им плевать на финансы владельца процесса.
Это если коротко.
Такой подход позволит отбрасывать очень много лишнего от происходящего. Но, на мой взгляд, стоит стремиться отдавать от "полевого уровня" только релейные сигналы (true/false) там, где это возможно.
Вам стоит перечитать то, что уже написано выше и попробовать понять суть идеи.
Вы предлагаете много лишнего, избыточного и бессмысленного, а самое главное - несвязанного между собой.
Ваша релейная автоматика здесь не подходит, поверьте мне. Я занимаюсь промышленной автоматизацией 30 лет и одновременно и микроэлектроникой и программированием и проектированием и разработкой.
Для всего нужен свой особый подход. Кувалдой можно забивать любые гвозди и арматуру можно вместо ремня использовать, но тяжело, не удобно, быстро устаешь, а самое главное - бессмысленно.
Я без оскорблений, просто критика. Можем подискутировать на любые темы, касательно автоматизации и электроники (и все, что рядом)
Rsa97
22.10.2026 15:11Как после полива может быть сигнал низкой влажности?
Не затрагивая остального, вот здесь всё логично. Устройство не знает, лилась реально вода или нет. Оно замкнуло контакты открытия клапана, через 10 минут (условно) разомкнуло. А если провод до клапана оборван? А если клапан заело? А если трубка засорилась? Поэтому ещё через полчаса (чтобы вода впиталась) снова проверяется влажность и, если она заметно не поднялась, надо включать сигнал об ошибке.
Coder007
22.10.2026 15:11Не затрагивая остального, вот здесь всё логично.
А вы затроньте и прочитайте всю ветку. Там не говорится про логику, там идет утверждение.
Оно замкнуло контакты открытия клапана, через 10 минут (условно) разомкнуло.
А на каком основании датчик разомкнет контакты? Он что реле времени? Задача реле влажности срабатывать от влажности! И да, при срабатывании он может размыкать (перекидной контакт реле). Даже если он замкнул контакты (потому что стало сухо), запустил насос полива, то разомкнуть он их сможет только если влажность появилась!
А если провод до клапана оборван? А если клапан заело? А если трубка засорилась?
То датчик влажности не отключится! У него повода не будет. И реле времени здесь - это ненужный элемент! Потому что если по нему еще контролировать, то это верх идиотизма. Вы сами представьте ситуацию и ее абсурдность!
Реле времени - это сценарий полива по времени, а реле влажности, это параллельный сценарий полива по влажности почвы. Как вы их будете связывать, а самое главное зачем, я не понимаю! Кто из них в приоритете, ддаже автор релейной автоматики не в курсе, потому что просто накидал чего-то на вентилятор и ушел довольный.
Поверьте, я не идиот, иначе не выносил бы такие утверждения и недоделанную логику вперед ногами.
Rsa97
22.10.2026 15:11А на каком основании датчик разомкнет контакты?
А на том, что если он будет ждать, пока измеренная влажность повысится, то может быть перелив. Вода же не моментально распределяется по всему объёму земли. Полито уже достаточно, а до датчика она ещё толком не дошла.
И да, при срабатывании он может размыкать (перекидной контакт реле).
Может. Но разрывать цепь для открытия клапана - плохое решение. В таком случае при обрыве провода клапан будет постоянно открыт и вода будет постоянно течь.
Coder007
22.10.2026 15:11А на том, что если он будет ждать, пока измеренная влажность повысится, то может быть перелив. Вода же не моментально распределяется по всему объёму земли. Полито уже достаточно, а до датчика она ещё толком не дошла.
Вы о чем? Сильно вы сами себе противоречите! В прошлый раз вы писали о том, что насос не отработал, а реле влажности, как то отключилось. В этом случае влажность не повысится, потому что не с чего! И насос продожит работать, а реле продолжит ждать повышения влажности.
Вот и написал вам, что: А на каком основании датчик разомкнет контакты? Если насос не отработал и вода не поступает!
У вас в вашей голове логика совсем не соотносится? Или у вас последнее сообщение не соотносится с предпоследним? Как вы можете писать про одно, а потом в воздухе переобуваться и пытаться опять меня выставить дебилом? А потом еще и писать мне сообщене с пометкой о том, что я написал хрень...
И да, при срабатывании он может размыкать (перекидной контакт реле).
Может. Но разрывать цепь для открытия клапана - плохое решение.
А кто вам вообще сказал, что он будет так делать. Я сделал акцент на то, что реле имеет пепеключающий контакт и подключить можно как вам вздумается!
А дальше я пишу: Даже если он замкнул контакты (потому что стало сухо)...
Где тут хоть слово про размыкание в рабочем режиме?
Как вы себе представляете запуск реле клапана при размыкании контакта? В релейной логике так не работает. Вы вообще понимаете принципы электрики, сигналов, какие бывают контакты реле, что такое датчики, как они могут работать или пишите ради того, что бы просто что-то написать?
Вы каким местом вообще читаете сообщения? Или читаете но не понимаете, ну тогда переспросите, объясню.
Rsa97
22.10.2026 15:11Сильно вы сами себе противоречите! В прошлый раз вы писали о том, что насос не отработал, а реле влажности, как то отключилось.
Да, отключилось. По заданному интервалу.
А на каком основании датчик разомкнет контакты?
А на основании того, что после включения прошло заданное время.
Вы, похоже, не работали с системами, в которых реакция сильно растянута по времени. Скажем, нужное количество воды выливается за одну минуту, а влажность в зоне датчика повысится до граничного уровня только через 10 минут от начала полива (напомню, вода не распределяется моментально по всему объёму горшка). Примитивная система, где только датчик влажности, будет поливать эти 10 минут и выльет в 10 раз больше воды, чем нужно. Нормальная система включится на минуту и поставит блокировку на 10-20 минут, чтобы вода гарантировано дошла до датчика.
. Я сделал акцент на то, что реле имеет пепеключающий контакт и подключить можно как вам вздумается!
Для чего делать такой акцент? Просто “чтобы было”? Ну сделали акцент. Я сделал акцент на то, что использовать эти контакты будет плохим решением. И?
Coder007
22.10.2026 15:11А на основании того, что после включения прошло заданное время.
Серьезно, у датчика влажности?
Ну видимо вы вообще не знакомы с системами автоматизации и автоматики если пишите такое про датчики влажности.
Я сделал акцент на то, что использовать эти контакты будет плохим решением. И?
И дно было пробито! Это невозможное решение! Потому что контакты, которые работают на размыкание никогда не включат нагрузку, а отключат ее.
А самое ужасное что вы не отслеживаете беседу и каждый раз пишете про что-то новое.
Вот вы занимаетесь администрированием сетей, а я автоматизацией и цифровизацией предприятий и вы мне доказываете что датчик влажности чудесным образом отключается по времени если насос не накачал воду по странной причине.
И что разомкнутый контакт включает нагрузку.
Какие здесь еще могут быть вопросы? Там один автоматик, который критиковал с точки зрения автоматики уже слился.
Ну если вы не обладаете компетенциями и на уровне бытовых контактов и реле даже не можете разобраться, зачем лезете и доказываете чушь!?
Зачем гадите в мозги тем, кто попросил решений. Вы же не дадите им ничего полезного, просто пытаетесь казаться умными что бы вами восхищались те, кто ничего еще не знают. Но здесь же не только новички обитают...
Rsa97
22.10.2026 15:11Серьезно, у датчика влажности?
А что, у самого по себе датчика влажности есть переключающиеся контакты? Он явно к чему-то подключен. И вот это “что-то”, скорее всего микроконтроллер, способно оперировать не только показаниями единственного датчика, но и другими параметрами.
Потому что контакты, которые работают на размыкание никогда не включат нагрузку, а отключат ее.
Да. Вот только исполнительные механизмы бывают самыми разными и отключение нагрузки может, например, что-то открыть. Например замок, который удерживается в закрытом состоянии подачей напряжения. Вы ни разу со СКУД не работали? Поэтому использование нормально замкнутого или нормально разомкнутого контакта, как и выбор исполнительного механизма, определяется тем, какое конкретно поведение нам нужно.
Coder007
22.10.2026 15:11И тут Остапа понесло.
Покажите схему и от этого будем отталкиваться, а от вашего воздуханства уже свербит.
Rsa97
22.10.2026 15:11А что вы хотите увидеть на схеме? Прямоугольник микроконтроллера, к которому подключены датчик, реле и два провода RS-485?
Coder007
22.10.2026 15:11Для вас это так выглядит? Вы же даже не понимаете, что для rs-485 нужен трансивер и желательно изолятор.
И реле тоже не подключается напрямую к микроконтроллеру.
И то, что вы описываете называется структурная или блочная схема. А в электронике и микроэлектронике и даже в релейной автоматике применяются принципиальные схемы.
Перечитайте ветки и если до вас дойдет, то вы увидите причину моего негодования.
Если нет, то не пишите "свои умные мысли" там, где вы вообще ничего не понимаете.
Вы изначально написали про реле влажности, а сейчас откуда то взялся непонятный безымянный датчик, какое-то реле и 2 провода rs-485, которые опять волшебным способом просто входят в микроконтроллер.
Для справки: нет ни одного микроконтроллера с прямым подключением rs-485.
Кому и что вы хотите доказать?
Coder007
22.10.2026 15:11Не затрагивая остального, вот здесь всё логично. Устройство не знает, лилась реально вода или нет. Оно замкнуло контакты открытия клапана, через 10 минут (условно) разомкнуло. А если провод до клапана оборван? А если клапан заело? А если трубка засорилась? Поэтому ещё через полчаса (чтобы вода впиталась) снова проверяется влажность и, если она заметно не поднялась, надо включать сигнал об ошибке.
Вот с этого все началось, а ваш комментарий был про устройство релейной автоматики под названием реле влажности. Ни о каком контроллере здесь и речи не было. Откуда вы вообще взяли датчик, реле и микроконтроллер и самое главное для чего там rs-485?
И даже здесь мы жиденько обделались запутавшись в логике работы простого датчика.
А реле влажности работает вот так: Реле влажности, ориентированное на увлажнение включается (на реле подается напряжение) при снижении влажнлсти до выставленного порога и оно имеет переключающий контакт. И в состоянии покоя контакт реле - разомкнут.
Когда уровень опустился до порогового уровня, оеле вклюючилось и запустило насос. При этом реле влажности не знает и не понимает, работает насос или нет, оно просто подало сигнал. И если по какой-то причине увлажнения нет, то реле никогда не выключится. Оно не микроконтроллерное, не обладает никакими другими свойствами, в нем нет реле времени. Оно будет подавать сигнал на увлажнение до тех пор, пока влажнось не достигнет другого порогового значения.
Вы скорее всего этого не знали и не знаете.
И кто будет его отключать, в релейной автоматике и будет ли вообще, это другой вопрос. Поэтому я и написал вам, нарисуйте СХЕМУ и потом поговорим!
И вас понесло....
Rsa97
22.10.2026 15:11Оно будет подавать сигнал на увлажнение до тех пор, пока влажнось не достигнет другого порогового значения.
То есть оно не годится для полива растений.
ваш комментарий был про устройство релейной автоматики под названием реле влажности
Давайте посмотрим всю цепочку комментариев:
Aleksandr_Lar: ну и для контроля я бы добавил логику: полив произошёл, сигнал низкой влажности висит.
Coder007: Как после полива может быть сигнал низкой влажности?
Rsa97: Не затрагивая остального, вот здесь всё логично.
Так что мой комментарий был про одну единственную вещь - как после полива будет низкая влажность.
Да, и откуда вы взяли, что изначально предлагалось использовать исключительно релейную схему без умного контроллера, мне тоже непонятно.Впрочем, оставайтесь при своём мнении. Лень мне спорить с человеком, у которого вся логика релейная.
Coder007
22.10.2026 15:11А вы часом не попутали?
Это разве я написал про релейную логику?
Вам лень ознакомиться с материалом, а доказывать свой бред, о том, что после полива сигнал низкой влажности - это логично, вы продолжаете.
Вы все мои комментарии почитайте, станет понятно. Ах да, вам же лень, вы же сисадмин. Из контекста вырывать вы мастак, а понять суть вам к сожалению так и не удалось.
Здесь речь об автоматизации, а не про коммутаторы, роутеры, каналы связи и маршрутизацию.
Coder007
22.10.2026 15:11То есть оно не годится для полива растений.
А голову включить, не?
Годится, но ему нужен дополнительный контроль.
Aleksandr_Lar: ну и для контроля я бы добавил логику: полив произошёл, сигнал низкой влажности висит.
Coder007: Как после полива может быть сигнал низкой влажности?
Rsa97: Не затрагивая остального, вот здесь всё логично.
То есть, для вас, здесь все логично? Идет полив, насос работает, а влажность не повышается.
Так что мой комментарий был про одну единственную вещь - как после полива будет низкая влажность.
Ну так вы и написали, что это логично, на абсолютно нелогичную вещь.
Да, и откуда вы взяли, что изначально предлагалось использовать исключительно релейную схему без умного контроллера, мне тоже непонятно.
Да вот потому что Aleksandr_Lar ни разу не упомянул про контроллер а только указал на реле:
Я бы предложил разбить подход на “узлы автоматизации”.
Самый минимальный уровень автоматизации - горшок.
Такой узел по сути состоит из двух реле:
реле времени на полив;
пороговое реле влажности.
Логика очень простая, задаётся двумя параметрами. В самом простом случае такая система также имеет свой бак с водой, для него критическим будет ещё одно реле - поплавок в баке, порог для которого задаётся один раз.
Схема работы такого устройства будет незамысловатая, причём наружу оно будет отдавать булевые сигналы:
запуск полива по таймеру;
запуск полива по влажности;
низкий уровень воды в баке;
ну и для контроля я бы добавил логику: полив произошёл, сигнал низкой влажности висит.
Или нужно догадаться, что он имеет ввиду в каждый узел поставить ПЛК, и потом центральный ПЛК? вариантов схем много и это не философия и не "угадай мелодию", а инденерия и здесь каждая деталь и нюанс меняет и логику и правила игры.
Если не умеете этого делать, анализировать, то спрашивайте больше.
Я сейчас реально вижу перед собой человека, который не понимая сути, доказывает мне что я идиот.
И да у меня от такого горит, особенно когда мой оппонент, даже не пытаясь выяснить, кто перед ним, называеь меня: человеком, у которого вся логика релейная.
У вас по всей видимости логика вообще вышла из чата...
Coder007
22.10.2026 15:11Вы, похоже, не работали с системами, в которых реакция сильно растянута по времени.
Я это проектирую, создаю и внедряю уже 30 лет, а вы даже логику одного датчика не можете описать. Взяли из своих фантазий несуществующее реле влажности и приписали ему функцию автоматического отключения по времени...
Wesha
Увидел в ленте заголовок «Ваш умный горшок должен принадлежать вам». Первая пришедшая в голову мысль была «ну ваще, они ИИ еще и туда засунули», но потом зашёл в статью и понял, что горшок всё‑так цветочный.
Coder007
Да, порой в заголовках, ввиду своей эрудированости, видим и 2 и 3 значения написанного. И что бы понять о чем речь приходится открывать статью.
Я пару дней назад наткнулся на статью, про безопасность конвейера. И что же мне пришло в голову в первую очередь - это промышленный ленточный конвейер! Но нет, это оказался программный конвейер.
Я в комментариях попросил автора в следующий раз указывать в наименовании статьи, какой конвейер он имеет ввиду. Но меня закидали минусами! А еще написали, что типа в первых строках поста сразу видно, о чем идет речь и что я идиот, если этого не понимаю. Но я то говорил про заголовок статьи, который я вижу в списке постов, а не про открытую статью...