Arduino Mega. Контроллер теплицы. Хроники

РЕКЛАМА НА ФОРУМХАУС

Я смотрю, обсуждать конкретные агротехнические требования Вы ещё несколько не готовы, хотя и сказали что этот вопрос важный, как никогда и, тем самым, "открыли ящик Пандорры" .

 

Конкретное агротехническое требование: при температуре выше 25 градусов открыть форточки. При температуре ниже - закрыть. Это решение можно настраивать как хочешь.

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

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

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

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

Если вас не затруднит словами описать алгоритм зависимостей между форточками, фоггером, температурой внутри и снаружи теплицы - буду только признателен. Чем больше взаимозависимостей - тем лучше, мне нужно понять, справится ли моя текущая реализация с такой задачей, или нет. И каков будет конечный объём сгенерированных правил.

 

@Cofessor, ок, пока при продумывании буду руководствоваться вот этими вашими словами:

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

 

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

 

Я думаю в формулировке этих требований не слишком ошибся. Если только с нижней температурой 12 гр. Южные культуру высаживают при температуре почвы не ниже 15-ти, ниже они вообще не растут. 18 - ещё лучше, но чем жёстче мы ставим условия, тем труднее их выполнить. Я ведь имел в виду некие усреднённые показатели, предельные, так сказать. Летом такой нижний порог выдержать - не вопрос, а как насчёт ранней весны и поздней осени? Тут ещё вопрос рентабельности обогрева возникает, поэтому для начала надо уловить общую логику. Температура 25 гр. тоже не с потолка взята - это оптимальная для томатов. Сможете обеспечить 25 плюс минус 1 - здорово, только во что это обойдётся? Может для этого Вам такие крутые исполнительные механизмы понадобятся, что копеечная система управления при этом уже не явится никаким плюсом.
Чтобы сделать климат-контроль в теплице, надо хорошо изучить агротехнику, чтобы понимать что именно и как регулировать, иначе никакая универсальность не поможет. Но я согласен что всё это можно и в дальнейшем совершенствовать, просто хотелось бы параллельно.

 

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

 

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

 

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

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

Я рад любому отзыву, но - стоит помнить одну старую фразу: критикуя - предлагай. Итак, вот скриншот:



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

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

З. Ы. Кто хочет пощупать тестовый интерфейс вживую - приаттачил архив, открыть test. html в браузере.

 

Гистерезис отсутствует. Открытие и закрытие форточек не может совпадать - будет наблюдаться беспрестанное открытие - закрытие форточек. Только поступит команда на открытие, как тут же поступит команда на закрытие, едва форточка начнёт открываться. Это быстро выведет двигатель из строя. Можно так сделать: Допустим t_zakr<22, тогда t_otkr>25, чтобы между ними был промежуток температуры.
Можно и одинаковую температуру, но тогда датчик, сработавший первым, запускает процесс, который нельзя прервать определённое время, следовательно сигнал с другого датчика будет игнорироваться до окончания этого временного промежутка.
Я вообще обдумываю вариант когда регулированием температуры в теплице (в т. ч. управлением форточками) будет управлять температура грунта на глубине 40-50 см., но это так, к слову.

 

Ну как отсутствует, а? Всё в ваших руках ведь, нет? Ну поставьте температуру открытия в >25 градусов, а температуру закрытия - в <24 градуса - гистерезис минимум градус. Ну не скачет температура как бешеная, это достаточно инертная величина.

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

 

Значит так: добил я таки связку правил между собой, проверил - работает, вернее - должно работать Потому что всё ещё не проверял - тестирование оно, цуко, вещь неспешная.

Как попробовать: в приложенном архиве есть папка TestUI - открываем оттуда index. html в браузере, жмакаем на всякие настройки, потом на кнопку "Сгенерировать" - в текстовом поле будет набор сгенерированных правил, которые уже можно скормить контроллеру по UART.

Текущая версия прошивки лежит в папке Main архива - открываем Main. ino в Arduino IDE, компилируем, закачиваем на плату, открываем монитор порта и рулим всякими командами.

Переписал модуль PIN13 - теперь он просто PIN, и умеет рулить любыми цифровыми пинами, сохраняя запрошенное состояние между вызовами. Можно также отказаться от поддержания состояния пина, подробности - в документации, папка DOCS в архиве.

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

1. Если температура внутри больше 25, то открыть форточки, работаем в любое время, продолжительность - 0 минут (сиречь постоянно работает). Остальные галочки (не выполнять если. .) ставить не надо.

2. Если температура внутри меньше 24, то закрыть форточки, работаем в любое время, продолжительность - 0 минут (постоянно работает). Остальные галочки (не выполнять если. .) ставить не надо.

Потом скормите это контроллеру в мониторе порта, на каждую команду должен придти ответ OK=..ADDED.

Потом скормите такую команду (эмулируем высокую температуру):

CTSET=0|PROP|STATE|TEMP|0|40

и посмотрите, как четыре форточки (сейчас их четыре, потому что я буду рулить мотор-редукторами с помощью реле, значит - по два реле на канал, а модуль реле у меня - восьмиканальный, т. е. на 4 форточки) будут открываться столько миллисекунд, сколько указано вами в текстовом поле "Время работы мотор-редуктора..." при генерации правил.

Потом введите (температура упала до двух градусов)

CTSET=0|PROP|STATE|TEMP|0|2

и посмотрите, как форточки отработают закрытие.

В общем, баловаться можно. Да уже и не только баловаться - на этой основе уже можно чего-то железянное делать, правда, сохранения настроек в EEPROM ещё не писано.

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

З. Ы. Как немножко устаканится синтаксис команд - допишу документацию на все модули. Ну и на очереди - разработка клиента-конфигуратора для PC, чтобы не копировать туда/сюда строки - надоедает слегка с консолью баловаться

Как обычно: пожелания, предложения, критика - ничего не будет лишним. Жду (с) Шпак.

З. З. Ы. Если вдруг сложности с генерацией правил - вот они:

CTSET=ALERT|RULE_ADD|N1|STATE|TEMP|0|>|25|0|0|_|CTSET=STATE|WINDOW|ALL|OPEN|5000
CTSET=ALERT|RULE_ADD|N2|STATE|TEMP|0|<|24|0|0|_|CTSET=STATE|WINDOW|ALL|CLOSE|0

 

Чёт я не понял. Вы просили высказаться? В скриншоте у Вас одинаковая температура? - Потому я и высказался. У меня это всё давно реализовано, и температуры закрытия-открытия разнесены и задержки вставлены. Именно потому что не скачет она и может испытывать микроколебания вокруг точного значения.
То есть температура после начала движения форточки ещё некоторое время может оставаться то ли на тысячную долю выше, то ли на тысячную долю ниже, что без гистерезиса вызовет выдачу противоположных команд. Мне кажется, этот эффект не устраняет даже усреднение параметра в цифровом датчике.

 

Ну блин. Да какая разница, какая на скриншоте температура - это вообще тестовая вещь. Можно при вводе предупреждать юзера, что гистерезис мал, например. Я вам объяснил, что понятие гистерезиса - не нужно, ибо это ущербная и лишняя сущность в данном конкретном случае. Вместо гистерезиса достаточно разнести температуры открытия/закрытия на градус, например - вот вам и гистерезис. Хотите гистерезис больше - разнесите на два градуса.

И всё - какой захотел гистерезис, такой и установил - никаких программных ограничений, каждый ССЗБ. И не надо специальных настроек гистерезиса на LCD-экранчике, не надо ничего перекомпилировать/обновлять прошивку, нет искусственных ограничений на этот пресловутый гистерезис.

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

А вы - на скриншоте нарисовано... Признайтесь - даже и не пытались скачать архив и пощупать, как можно менять правила? Впрочем, не удивлён - я уже давно привык к тому, что редко кто в интернетах читает вдумчиво. Это не нападка, отнюдь - у каждого свои проблемы и интересы, и я не вправе требовать от кого-бы то ни было вдумчивого участия в обсуждении. Однако, также не стоит искать проблему там, где её нет: ведь с гистерезисом вы были не правы, именно по причине некритического рассматривания скриншота. Там ведь видно, что есть поля, куда можно ввести температуру, значит, граничные значения могут меняться.

Вроде всё, умолкаю.

 

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

 

Вижу, отредактировали сообщение, поэтому отвечу на добавленное. Нет такой проблемы в моей реализации, и вот почему: допустим, у нас есть два правила:

1. Закрыть, если температура меньше 24
2. Открыть, если температура больше 25.

Смотрите - температура, например, 24 - ничего не делаем. 23,9 - закрываем. 24,1 - ничего не делаем. 24,9 - ничего не делаем. 25 - ничего не делаем. 25,0001 - открываем. На микроколебания - пофиг хотя бы потому, что у меня дискретность - ОДИН градус, я отбрасываю значения после запятой, они мне не нужны для управления форточками. Да даже если бы и не отбрасывал - на приведённом примере я показал, что лишь установкой граничных параметров можно добиться появления гистерезиса.

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

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

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