Как стать автором
Обновить

Основные принципы организации микроклимата в закрытом грунте

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров2.5K
Всего голосов 7: ↑6 и ↓1+5
Комментарии52

Комментарии 52

Спасибо. Дельное дело :)

Насчёт отопления тепловым насосом (кондиционером по сути) недавно была эпичная ломка копий, мне вот не пришло в голову ничего более умного, чем просто большая площадь наружного блока (чтобы успевал приходить в равновесие с окружающим воздухом быстрее, чем обрастёт льдом по самые уши). То есть трубки придётся крепить к огромной плите из редкоземельного чугуния (которая по цене как крыло от боинга), да ещё желательно её на солнце выставлять — а южная сторона обычно занята окнами, собственно, самого зимнего сада/оранжереи/теплицы.

Из грунта брать тепло — грунт промерзает, из воды — рядом как минимум река нужна, если не океан.

Есть какие мысли по этому поводу?

Есть какие мысли по этому поводу?

а есть вариант выкопать яму до грунтовых вод, проложить в них теплообменник (вот вам и "река") и закопать яму обратно ?

Да, делают гидротермальные штуки для тепловых насосов именно с помощью скважинного неглубого поля (десяток скважин до 10-20 метров). У воды в скважине постоянная температура. Можно из колодца тоже что-то подобнео соорудить наверное

Вот вроде на них как раз финны жаловались, что дальше «ниже по течению грунтовых вод» почва весной оттаивает намного медленнее. Но это не точно. Мог перепутать.

Почему не вытяжка?

Потому что нас интересуют закрытые контуры, только CO2, только хардкор!

Ну на определённых объёмах выгоднее получается всё-таки вытяжка + восполнение потери CO2 за счёт подачи углекислоты из баллонов...

А в целом спасибо за статью, жду продолжения, где будет раскрыто обещанное в первом абзаце " как измерить температуру и влажность воздуха в твоей теплице" :) Температуру-то ладно, можно хоть через каждый метр копеечных DS18B20 навешать. А вот влажность уже интереснее, а СО2, который тоже надо мониторить - ещё интереснее. У меня сейчас температуру/влажность меряют Овен ПВТ-110, если добавлять СО2 тоже от Овена - можно разориться. Всё в одном есть у WirenBoard (WB-MSW), но он только во внутреннем исполнении, для теплицы не очень удобно (но за разницу в цене с Овеном можно пережить и поставить на герметик в коробки)

Температуру-то ладно, можно хоть через каждый метр копеечных DS18B20 навешать. А вот влажность уже интереснее

Совмещенными MEMS-датчиками температуры/влажности :) Они достаточно точные и по температуре и по влажности. Вот на фото три датчика, висящих рядом друг с другом, показывают практически один-в-один.

Но тут надо свой измеритель делать, Овены проходят мимо :)

Совмещенными MEMS-датчиками температуры/влажности

Это типа WHT30, шина I2C? Так себе для теплицы с т.зр. максимальной длины проводов к датчикам.

Конечно же по проводам гнать не I2C, а что-нибудь вроде RS485.

Ну так добавлять к каждому датичку по микроконтроллеру, который будет I2C читать и по Modbus передавать - и геморройно, и затратно, и лишняя точка отказа. Проще уж брать датчики с RS485 сразу (ну или 2 выхода 4...20 мА как вариант)...

Так в этих датчиках все равно будет стоять тот же МК, просто ставить его будете не вы, а условный Овен :) Так что по точкам отказа оно примерно одинаково. По финансовым затратам тоже еще не факт, что готовый выйдет дешевле. Вот по затратам времени - да, на самодельный вариант придется потратить время.

Ну быстрый гуглёж показывает, что готовое есть в разных ценовых категориях. Китай около 1000 руб. - по отзывам работает через раз (ну ожидаемо); около 5000 руб. (какая-то "Доступная автоматика") - уже выглядит как Овен, стóит попробовать; Овен за 15 000 руб. - тут точно лучше, чем я сам, сделают, но цена (хотя кто ж Овен покупает за полный прайс, его на Авито ловят за полцены :)

Но мне больше всего упомянутый выше Wirenboard WB-MSW пока симпатичен, т.к. там ещё и датчик CO2 в комплекте, и всё счастье в такой комплектации на 3 параметра с RS485 за 7900 руб.

Самодельный выходит в районе 2000 руб - это комплектующие и плата :)

Скрытый текст

Ну я не настоящий сварщик электронщик, я свою плату распаять не осилю, да и из готовых компонентов у меня вряд ли получится надёжнее, чем у тех китайцев за 1000 р. (это на Озоне, на Али явно дешевле). Так что мне проще уж купить мешок китайских датчиков и менять по мере выхода из строя :) Ну или всё-таки WB-MSW.

А, ну да, я чет по себе примеряю. Согласен, большинству проще подобрать и использовать готовое :)

Да хотелось бы всё освоить самому, но, блин, в сутках 24 часа. А применительно к сельхозтеме на своём "огородике" на 10 га :) я и так в одном лице проектировщик всего, строитель, монтажник, юрист и финансист. Матчасть и программное обеспечение тяну - и то рад, на пайку железок времени никак не остаётся. Ну может потом, на пенсии :)

загляните к нам на сайт или в канал (в профиле) :)

Сорри, но в профиле у Вас ни того, ни другого.

Сначала написал, потом проверил (теперь ссылки есть), вот лучше в канал сразу, там фоточки понятнее http://t.me/project_kolkhoz

Вкратце: мы делаем удобные интерфейсы к ESP32 для разных китайских датчиков По поводу CO2, посмотрите на scd40 и scd41, длина I2C позволяет использовать несколько десятков сантиметров витую пару, этого хватает чаще всего

Ох, ESP32 штука хорошая, но до определённого масштаба...

длина I2C позволяет использовать несколько десятков сантиметров витую пару, этого хватает чаще всего

В теплице нужно несколько десятков метров :) Ну или по микроконтроллеру в каждом углу.

На самом деле проблемы нет: в каждом углу висит DHT22 (который спокойно работает на десятках метрах), CO2 датчик висит в одном углу, например, самом дальнем от редуктора/источника CO2.

Про масштабы, хочу услышать про ограничения :)

Ограничения - ну смотрите. У нас есть теплица. Даже не тепличный комбинат, а стандартные фермерские 500 кв. метров. В ней уже в "полном фарше" (три контура отопления, вентиляция форточками и принудительно, подача CO2, освещение, автополив, фертигация) десятка полтора исполнительных устройств и десятка три-четыре датчиков. Когда там у ESP32 ноги закончатся? Понятно, что можно несколько таких ESP32 как-то друг с другом поженить - но это уже отдельный костыль, который надо проектировать и реализовать. На ПЛК это просто добивание модулей ввода-вывода до нужного числа по мере потребности.

Идём на уровень выше. У нас же таких теплиц не одна, а скажем 20 (как раз на гектар). Автоматика каждой из них должна скидывать данные в единую систему контроля и мониторинга. С ПЛК просто - OPC UA из коробки (ну или MQTT), цепляем к SCADA, рисуем красивые дашборды и полезные алерты, наслаждаемся. ESP32 в MQTT тоже теоретически умеет, но это опять надо писать и настраивать.

Ну и главное - когда контроллеров десятки, а датчиков сотни, всё это регулярно выходит из строя, и заменить из подменного фонда должен уметь любой гастарбайтер, который окажется рядом. Так что тут стандартизированные решения с минимальной настройкой решают.

Ну и вообще, ESP32 хороши беспроводными интерфейсами, низким энергопотреблением, низкой ценой... Для больших площадей первые два пункта не актуальны вообще, третий не так критичен на фоне других затрат на строительство такой теплицы (те самые 500 кв.м чисто фундамент/каркас/плёнка - под миллион, вообще без инженерки).

В больших проектах берется столько есп, сколько нужно, хоть 10. Если вифи по каким-то причинам не устраивает, есть езернет или модбас. Женить их надо не с друг другом, а с Home Assistant, накидали на одну есп 10-20 датчиков, взяли следующую. И все хорошо работает и с десятком контроллеров и сотней датчиков.

Не-не, выносить на уровень выше можно мониторинг и ручное управление. Все сценарии автоматического управления должны быть в одной железке, чтобы при пропадании связи с этой железкой или сбое в сервере вышестоящего уровня (хоть SCADA, хоть HA - в целом, так-то, и HA, и Node-Red вполне себе SCADA) они продолжали работать. Так что разделение на контроллеры возможно, если все подключенные к нему датчики и исполнительные устройства образуют достаточно автономную группу с т.зр. сценариев автоматического управления техпроцессом.

Все так. Логика (сценарии, неделимые транзакции, как угодно назовите) шьется на есп, мониторинг сверху. Противоречий нет

Так я о чём и говорю! Пока для реализации сценария достаточно датчиков и управляющих устройств, подключённых к одному ESP, всё ОК. А если от полутора десятков датчиков температуры, влажности и СО2 (первые два показателя - и воздух, и почва) зависит и запуск вентиляции (приводы форточек, вентиляторы), и запуск отопления (клапаны трёх контуров, и там плюсом свои датчики температуры и давления теплоносителя), и подача СО2, и освещение, и даже полив разных зон с фертигацией, а ещё там надо мониторить хотя бы наличие напряжения, а лучше тока, на всех вентиляторах/насосах/приводах, чтобы понять, что они не сгорели, а реально включаются, - то мы все эти сценарии на одной ESP не сможем реализовать. А как ни рисуй сценарии, всё получается взаимосвязано в рамках одной теплицы.

Ну вы в кучу все намешали, так конечно сложно и непонятно. В реальных условиях есть, например, растворный узел. Он мешает удобры и он довольно замкнутый. Все умещается в рамках одной есп/шилда (перистальтические насосы и пш/тдс датчики).

То же самое с климатом и светом. И даже если все действительно так сложно и непонятно, как вы рассказываете, то:

  • есть мультиплексоры, хотите хоть 30-40 аналогоывх датчиков влажности почвы влепим на есп. Не делаем и не рассказываем про это, потому что пока никому не требовалось.

  • две строчки в конфиге и две есп могут обмениваться данными с друг другом. Это если уж совсем сложная логика.

При этом, все критичные действия все равно шьются на есп как отдельные логические скрипты/сервисы. То есть одна есп инициирует действия на другой, поэтому проблемы с сетью никак не влияют (посередине процесса ничего не отвалится)

Вот я как раз пытаюсь от замкнутости уйти. А то именно что купить растворный узел или контроллер полива каждый со своим закрытым ПО - вообще не проблема. А хочется всё увязать на стандартных открытых протоколах. Не то, чтобы вот завтра у меня появится всё и сразу. На следующий сезон дай Бог запустить две теплицы по 500 квадратов без отопления пока. Полив уже есть в открытом грунте, с ним всё понятнее, вентиляция/СО2 - вот вникаю. Но хочется заложиться на перспективу потом как угодно добавлять в систему новые кирпичики и тасовать существующие. Выбор архитектуры - это как выбор фундамента для дома, потом уже менять поздно будет.

Вариант "одна ESP инициирует действия на другой" - ну да, ОК, вот это и есть "женить их друг с другом", про что я выше писал :) Опять же, не буду дальше обсуждать сферическую систему в вакууме. Напишете про свою - будет очень интересно. Ну а я, надеюсь, годика через три смогу не без гордости написать про свою :)

Я хотел написать в прошлом комментарии, но решил что и так много букв.

Вы писали про надежность, это конечно важно, но относительно надежно будет работать любой продукт на рынке. Тем более коробочный с закрытым ПО. Только оказывается, что каждая теплица уникальна и каждого фермера свои запросы и пожелания. Более того, часть вещей хочется в будущем изменить (например, сейчас воду с кондеев сливаем в канализацию, а хотим потом собирать, фильтровать и обогащать калмагом).

Замкнутая я написал в том смысле, что она будет работать автономно, но она будет открыта для остальных устройств (другие esp, home assistant, web view, api rest). При этом протоколы есть и будут открытыми, это все опенсорс.

И дело даже не в том, что можно подключить буквально все возможные датчики на рынке (цифровые, аналоговые, modbus, uart, whatever), а что поверх этого можно накрутить любую логику. И логику можно накрутить и скриптами прямо в железе, а можно накликать в веб-интерфейсе на HA. Вы ограничены только своей фантазией. И все это за копейки.

Я не говорю уже OTA обновления, приложения на телефон, это все в базе есть.

Так я понимаю, что мы про одно и то же концептуально, просто на разной базе. Я начинал делать на ПЛК Овен, но суровый мир языков IEC и CodeSys для меня оказался чересчур суров, и сейчас у меня трудится Wirenboard (а вот датчики Овен в основном). Раскатать конфигурацию на контроллер через Ансибл и мониторить его в Графане - прекрасно же, все привычные инструменты в деле. Как оно там в мире ESP - знаком поверхностно, исходя из текущего впечатления - там должно быть тесновато по аппаратным ресурсам и в связи с этим по выбору применимых технологий. Но почитать подробнее интересно именно на живом примере, близком моим задачам. Чем Ваш пост и зацепил, что уже который коммент к нему строчу :)

Представьте, что все ещё проще и удобнее, чем ансибл и графана (при всей моей любви к энсиблу, а вот графана никогда не нравилась).

Мы сейчас готовим околокоробочный продукт, скорее демонстрационный комплект, его подробно опишем и покажем. Прямо живую теплицу получится продемонстрировать не ранее чем через пару месяцев.

Жду, подписался :)

А Графана прекрасна, если её научиться готовить, но именно от неё в этой части придётся отказаться, потому что нужен мониторинг и ручное управление в одном месте: не просто смотреть график температуры, но из того же дашборда установить целевое значение, что-то включить/выключить. А это уже SCADA (даже если мы её реализуем не на каком-нибудь Ignition за 15к баксов, а на HA; я пока остановился на Fuxa, но не факт, что это окончательный выбор).

Какая-то выдуманная проблема. Т.е. со своими скадами итп когда заканчиваются входы впихнуть ещё один модуль можно, а когда они кончатся у чего-то другого - это зашквар :)?

Но вы правы, весь вопрос в деньгах и квалификации. Если денег много, то смысла что-то делать в целом нету, лучше заказать готовое "под ключ".

А когда их всего несколько чемоданов приходится раскорячиваться.

Совершенно верно, проблема в деньгах. И дороже всего не железки, а люди. Которых, внезапно, приходится нанимать, если объёмы выходят за пределы любительского огородика.

Поэтому Home Assistant, в котором HMI дашборд рисуется только с бубном, а для нормального управления алертами надо бы свой плагин написать как минимум, - это дорого. Ignition, где всё это и куча другого ещё из коробки, но лицензия 15k$ - тоже дорого. А вот Fuxa, где надо поизвращаться (документация мрак), но в целом всё реально сделать в одно своё собственное лицо, ну и оперсорс, - это недорого.

Поэтому датчики и контроллеры, которые надо паять, прошивать, программировать с нуля и текстом, придумывать самодельные корпуса и т.п. - это дорого. А ПЛК и модули к ним, в которых и в программной части уже зашиты нужные "кирпичики", и аппаратно он уже готов с корпусом, и если что - из него рабочий выдернул клеммник, воткнул в новый, а дальше весь конфиг восстановится удалённо, - это недорого.

Совершенно не факт, что на ESP, китайских датчиках и HA нельзя путём некоторых усилий создать систему, которая будет легко настраиваться и обслуживаться, - но вот тут как раз хочется подробностей

Ну если все уже посчитано, и люди дороже, то тут уже ничего не поделать. Придется страдать с плк всякими. Совершенно правда непонятно чем отличаются клеммы ведущие к какому-нибудь есп32, и почему их труднее коммутировать, но верю на слово.

У меня перед глазами несколько компаний вполне себе на черную икру зарабатывают. Как-то они смогли наладить выпуск своей электроники для эксплуатации неквалифицированным персоналом. Сдюжили даже что-то куда-то припаять :). И корпуса тоже сдюжили. И еще очень многое...

Т.е. я точно знаю, что некоторым удалось собирать свои системы не из чужих пропиетарных решений, а из своих.

Но, безусловно это возможно не всегда и не везде.

ЗЫ. Датчики, обычно все китайские, ну может некоторые тайваньские... Их. Самих детекторов единицы и они у всех совершенно одинаковые. Других взять попросту негде.

По-моему, мы о разном. У кого-то бизнес выпускать электронику, и я буду рад, если они осилят выпуск и дешёвой, и лёгкой в эксплуатации, и открытой и т.п. системы. Незамедлительно куплю :) Возможно, это автор поста будет, может кто-то ещё.

А у меня бизнес (и ладно бы единственный) - выращивать цветы и ягоды, и на своих 10 Га я и так всю инженерку проектирую и монтирую в одно лицо. Мне точно некогда ещё параллельно изобретать свои велосипеды. И я не могу на ферме присутствовать 24*7, так что возможность починить что угодно без моего физического присутствия, и очень вдумчивый мониторинг - обязательно...

Автор уже все перечисленное делает :D

Смотрите, не нужны ни скада, ни плк, нужны дешевые китайские датчики и несколько есп. Вот реальный дашборд, правда объект разбирается и часть уже не работает.

3 есп на наших шилда и ассорти каких-то датчиков. Все работает настолько хорошо, что я даже пытаюсь сделать из этого бизнес. С нашим железом все подключается за пять минут, ESPHome все настраивается за те же 5 минут, а дальше все инфа сводится в Home Assistant. У датчиков секундное разрешение, если что-то происходит вы узнаете за минуты и вам приезжает пуш на телефон. Данные можно хранить в КХ и иметь историю за года в таком разрешении. Хотите, оценивайте на дневных графиках рост и здоровье. Хотите, поделите на зоны и делайте реалтайм продуктовые эксперименты (на продуктах лол)

Если что-то отвалилось (хотя оно не отваливается само, отваливается от кривых рук чаще), взяли новый датчик у нас или даже на Алике, переставили со старым и все продолжило работать. Можно делать вообще не приходя в сознание, гастарбайтер тоже справится.

Вот как раз про HA спорить не буду. Я сам Node-Red использую (правда, на контроллере чисто для сценариев, а не на верхнем уровне), и как понимаю, функционал сопоставим, и да, при должной настройке это вполне можно назвать SCADA-системой (да простят меня суровые асутпшники). Просто специализированные SCADA-системы из коробки удобнее (но с опенсорсностью там плоховато, ну в общем это отдельный разговор, хоть свой пост пиши про выбор SCADA, когда на неё жалко денег :)

Скриншот Ваш с точки зрения UX ужасен, конечно, сорри :) Но это, думаю, исправимо.

Вообще, интересно было бы про Ваше решение почитать подробнее. И с физической стороны (вот эти все ESP32 и китайские датчики надо ж по каким-то коробочкам разместить, шлейфы там, разъёмы), и с программной (как, скажем, накатывается конфигурация на новый ESP32, когда его надо быстро поставить вместо предыдущего, который трактором раздавили :) Для меня вопрос вот прямо практически актуальный. Ни один фермер не откажется снизить затраты на автоматику с условно полумиллиона на теплицу до условно ста тысяч, но если это будет не ценой снижения надёжности и обслуживаемости.

Да, напишу, но потом :). В нашем борделе пока мало людей работает...

Общий план по железу можно тут посмотреть https://youtu.be/v4sQmk0XMxM

По размещению, все индивидуально, можем шкаф вам собрать, можно по разным коробочкам сделать.

Если раздавили трактором, шьем из браузера по микроусб новый МК

esp32 devkit DONT DO IT
esp32 devkit DONT DO IT

и вставляем в шилд на месте старого

Видел I2C датчики влажности, висящие на проводе с десяток метров длиной. Лютое нарушение всех норм, но как-то работали :)

Так при наличии хороших проводов это не проблема. Ключевой вопрос: зачем ? МК ныне недороги, их можно в каждый датчик без проблем запихать, уж не говоря о нескольких штуках.

Зачем - этого я не знаю. Так решили те, кто делал ту систему :)

" больше устройств, меньше точек отказа " - вот тут что-то с логикой случилось...

P.S. Датчики влажности (почвы) в теплице несколько лет уже использую типа SHTx0, в waterproof-исполнении (корпус из прессованных металлических шариков), а дачный дом отапливаю тепловым насосом воздух-воздух (эффективен почти всегда, кроме морозов ниже -15).

вот тут что-то с логикой случилось...

У тех, кто RAID использует, тоже проблемы с логикой?)

Логика такая: один большой кондиционер уходящий в отключку либо все переводит в аварийный режим, либо у вас все погибает от жары.

На N-1 кондиционерах можно перевести теплицу в менее аварийный режим / деградацию по мощности не приводящая к отказам.

У вас просто неверное выражение. Больше устройств - больше точек отказа, это вам написали верно. Просто при дублировании устройств повышаются шансы пережить одиночные отказы :)

Нет, вы не понимаете, что такое точка отказа.

Единая точка отказа (англ. single point of failure, SPOF) — узел системы, отказ которого приводит к её неработоспособности (т.н. каскадный отказ).

Теплица работает если есть свет, вода и кондиционирование. Несколько кондиционеров убирают точку отказа с кондиционирования. И пример с RAID именно про это. Больше жестких дисков, но точек отказа меньше, даже вылетающий диск не становится отказом в системе.

Это единая точка отказа, которая приводит к неработоспособности всей системы. А просто точка отказа может привести к ухудшению качества работы системы, или потери ею каких-то отдельных функций, но не к полному отказу. В принципе, любой узел системы является потенциальной точкой отказа. Если его неисправность приведет к полной неработоспособности системы, то это единая точка отказа, например это вводной автомат в электрощитке, без него вся система окажется нерабочей. А если, например, произойдет отказ индикатора кондиционера, то это никак не повлияет на работу всей системы.

Вы почти сами пришли к мысли, что выражение "точка отказа" само по себе несет мало смысла, в отличии от "единой точки отказа"

Оно несет просто другой смысл, а не мало или много, в этом и дело :)

А кондиционер у Вас будет каждый отдельным контроллером управляться? Если нет - мы просто сдвигаем единую точку отказа в другое место. Если да - кратно усложняем систему из-за необходимости увязать друг с другом работу множества контроллеров.

Если уж говорить про аналогию с RAID - тут должно быть не разделение на автономные части, а резервирование. Чтобы при отказе одного контроллера автоматически включался в работу резервный с теми же настройками (кстати, как такое на ESP32 реализовать - легко?). А при отказе одного из кондиционеров подключался ещё один, стоявший в резерве. Но это, блин, уже следующий уровень, я даже не замахиваюсь пока (вот только в газовой котельной, которая пока не подключена, именно так - два котла по 500 кВт, можно на свой страх и риск включить одновременно, но лучше один держать в резерве, ибо теплицы оставить без отопления в мороз даже на час - это катастрофа). Сделать бы мониторинг, который вовремя предупредит о проблеме.

Сейчас вы взяли вымышленную ситуацию и сказали, что она плохая. Кондиционер действительно может управляться каждый одним контроллером, а может и не одним, это вообще без разницы. Более того, от поломки управляющего микроконтроллера , сам кондиционер работать не перестает.

"Кратно" система не усложняется от нескольких микроконтроллеров, сложность в данном случае растет линейно и слабо зависит от количества микроконтроллеров.

Основная проблема: определить что такое отказ, а уж дальше можно как угодно эту ситуацию разрулить на какой угодно аппаратной и программной базе.

При наличии оборудования правого борта и оборудования левого борта качественный капитан чтящий устав, находясь в походе регулярно переключается с одного борта на другой.

Потому как никак иначе работоспособность резервного оборудования не гарантировать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории