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

Приветствую уважаемых!

Disclaimer, как водится

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

Вступление

Есть у меня теплица. Ну как есть - строю я её. Не спеша так строю, второй год уже. Мееедленно, как ленивая улитка - не потому, что ленивая и не от того, что улитка, просто - дел куча, то - ремонт, то - стройка, поэтому теплица, хоть и в приоритете - строится в свободное время. Собственно, каркас её уже готов - 16х4 метра, из профильной трубы 25х25мм. Осталось покрасить на пару-тройку раз, замостить поликарбонатом, и - запускать в эксплуатацию. А, нет - не запущу, потому что...

Автоматика

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

И купил я у китайцев чудо чудное, диво дивное - зверя заморского с гордым именем Arduino Mega. И начал свои эксперименты. О них, собственно, далее...
https://github.com/Porokhnya/GreenhouseProject

 

Задачи для себя я нарисовал амбициозные. Хотелось, для начала, управлять микроконтроллером отовсюду, откуда только можно: непосредственно жмакнуть на кнопочку железянную - нате вам. По Wi-Fi с домашнего компьютера - извольте. По витой паре - да как об асфальт сами знаете что! Со смартфона - не вопрос. В голове такая красивая картина нарисовалась - аж жуть, до умиления и зелёных соплей. Короче - залип я.

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

Не люблю я писать код. Вернее - программировать-то я люблю, вот только писать бездумно - не очень. А тут - управлять отовсюду бедной Mega, тоже мне бином Ньютона, казалось бы! Думал думал, решал решал, и - сделаю, сказал себе. Задача ставилась такая: я заранее не знаю, какой функционал мне надо будет дописать, это раз. Не хочу некрасивого кода простынями по нескольку экранов в одной функции - это два. Система будет модульная - это три. Модули могут быть как в пределах одной коробки, так и разнесены в пространстве - это четыре. Модули должны поддерживать прозрачное общение друг с другом "из коробки" - это пять. Ну и, конечно, нужна лёгкая расширяемость поддерживаемых команд - это уже, значится, шесть.

 

Что делать, когда в наличии только Arduino Mega, а остальной обвес идёт черепашьей почтой? Правильно - программировать! Тестировать, отлаживать, писать глюки, ловить глюки, наесться глюков до отвала, чтоб стошнило, потом стереть всё, что написано - и написать заново.

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

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

В-третьих, разные потоки публикации. С чем это едят, спросите вы? Ну допустим, что есть у вас код, который опрашивает датчик и выводит температуру на экран. И захотели вы, помимо вывода на экран - выводить всё это в Serial. Да не просто выводить, а по запросу из Serial же. Короче, уже представляете, сколько зависимостей, да? А вот и нет! Не надо специально корячиться и переписывать модуль для вывода на экран - архитектура, повторюсь, такова, что модуль только отдаёт или устанавливает свое внутреннее состояние, по запросу извне. Откуда пришёл запрос - ему чхать, куда всё это выведется - наплевать. И вот на этом моменте вы подключаете к этому модулю модуль публикации на дисплей (одной строкой кода) - и всё! Просто, правда?

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

 

Итак, что я сделал за эти дни? Раз есть одна Мега и один комп - будем общаться через Serial. Ах да - на Меге есть встроенный светодиод на тринадцатом пине - вот его, болезного, и будем мучать. А ещё - сделаем поддержку циклического запроса/записи всяких команд для модулей, да вывод статистики (вроде аптайма и свободной памяти) - тоже прицепим.

И вот сижу я сейчас, смотрю на подключенную к USB мегу и радуюсь. Открываю монитор порта, вбиваю туда команду вида:

CTSET=PIN13|ON

и диод загорается. Пишу

CTSET=PIN13|OFF

и он гаснет. набираю

CTSET=PIN13|T

и диод меняет свое состояние. Хочу получить его состояние - пишу

CTGET=PIN13

и любуюсь полученным. А ещё - могу заставить его помигать столько раз, сколько мне нужно, например, 10 раз в секунду, целую секунду:

CTSET=LOOP|SET|100|10|PIN13|T

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

CTGET=STAT|FREERAM

выдаёт количество свободной памяти, а если его попросить

CTGET=STAT|UPTIME

то он покажет кол-во секунд с момент старта контроллера.

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

 

Ну и, как водится, для ценителей прекрасного - исходники. Достаточно открыть их в Arduino IDE и загрузить на плату Mega. Как поиграться - я описал выше. В исходниках есть комментарии, разобраться не составит труда.

Код, конечно, писался по живому, так что AS IS, что называется. Мне главное сейчас, как в песне поётся, "оценить красоту игры". И да - обратите внимание на код в loop - по идее, он и будет таким крохотным, всё остальное добро должно пихаться в модули.

Если есть какие-то вопросы/пожелания - задавайте. И давайте не забывать, что всё это пока только наброски, а конечный продукт предполагается в виде контроллера теплицы на базе Arduino Mega.

А пока - курите доки, они рулез.

 

Да, беда, уровень Ваш, как программиста, - ого-го, кабы не схемотехника, плевать бы Вы хотели на Arduino, не так ли?
Хотя, Меги в любом случае хватит.

 

Даже не знаю - плевать или не плевать Мне просто интересно возиться с мк, а, т. к. по схемотехнике я не очень - понятное дело, что конструктор типа ардуины - самое то: это не то место, где можно особо сэкономить, ведь речь не идёт о серийном производстве, всё чисто "для сэбэ". Не хватит Меги - да пофиг, куплю Raspberri PI - код можно легко под неё портировать, там по сути-то - голый С+, вся специфичная для ардуины работа - в паре классов, которые и переписать недолго.

А пока - опыты, опыты

 

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

А тут - опа: приезжаю на почту, а там - восемь посылок! Пришло барахлишко моё всякоразное: модуль реле, электромагнитный клапан на 12В, для тестов с поливом, значит. Модули для работы по RS485 - ажно 4 штуки (руки-то загребущие ). GPRS-модуль - буду пробовать рулить мегой по СМС (помните, да, как легко программно добавить модуль в предлагаемую систему?). Модуль работы с флешкой. Ещё чего-то по мелочам. Добби визжит и доволен - новые цяцки в хозяйстве появились, ляпота!

Короче - форум чего-то там делает в подпространстве. Пожалюсь тогда и сегодня, авось - завтра ещё посылка свалится - жаль, не пришли ещё датчики температуры, уже так хочется их приколхозить, зубы ломит! Да и резисторы в наборе "за рубль кучка, всякоразных и по многу" - чего-то тупят, сопротивляются, значит - диалектика, всё строго по их жизненному кредо Ну надоело мне прозванивать старые платы и выпаивать оттуда резисторы нужных номиналов, на-до-е-ло!

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

З. Ы. Пришёл ещё один из двух заказанных тапенеров, но это - история другая, совсем не про электронику. Шо за зверь, спросите вы? Арргх, какой классный, рекомендую Пилите, Шура, пилите - гугль знает, что такое "тапенер"

 

Это да, ардуино почти полностью избавляет от проблем с электроникой и программатором. Остаётся только правильно запитать, защитить от помех и смонтировать в маленькую коробочку.
Я через Алиэкспресс заказываю. Правда экспресс - сильно сказано. Первый заказ делал где-то в начале ноября, 3 позиции так и не пришли: датчики и RTC. Заказал их вновь примерно 20 декабря - пока тоже ничего, в железе без датчиков нечего проверять, жду.

 

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

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

CTGET=TEMP|Sensor1

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

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

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

Как узнать, что запрос надо перенаправить к сторонней коробушке, если у нас нет датчиков температуры, подключенных прямо к контроллеру? Или же - если они есть, но переданное имя - имя не нашего датчика? Очевидно, что тут два пути: отправлять команду всем модулям, подключенным к контроллеру (в надежде, что кто-нибудь ответит), или - добавлять поддержку чего-то типа конфигурации для модуля, где будет описываться информация о том, на какие команды может отвечать модуль. Первый путь мне видится предпочтительным, потому как, будь то RS485 или Wi-Fi для связи между модулями - я легко "из коробки" могу послать широковещательное сообщение всем подключенным сторонним коробочкам, и если кто-то ответит на запрос - значит, так тому и быть.

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

Буду думать.

 

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

Да просто ведь же всё! При первом подключении сторонней коробочки к главному контроллеру для неё просто регистрируется свой модуль в главном контроллере, с именем - да с тем именем, которое отдаст нам коробочка при подключении. А далее - всё просто (на примере коробочки с именем "DEVICE1"):

CTGET=DEVICE1|TEMP|Sensor1

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

TEMP|Sensor1

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

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

 

Дописал поддержку потока регистрации новых модулей. По умолчанию он носит имя "0", по идейным соображениям. Зачем оно надо, опять же? Давайте смоделируем следующую ситуацию: модули у нас подключены в сеть. Пусть это будет сеть на основе RS485, считаем, что сеть работает с арбитражем, т. е. говорить могут все, когда хотят, но по умолчанию опрашивает дочерние устройства контроллер, конечно.

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

Так вот, об чём речь: включилась такая коробочка в общую сеть, да и послала сообщение

CTSET=0|ADD|YA_KREVEDKO

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

CTGET=YA_KREVEDKO|TEMP

Вуаля! Контроллер понимает, что надо бы опубликовать в сеть сообщение (сообщение во внутреннюю приходит всем модулям сразу, на примере RS485) такого же ровно вида,

CTGET=YA_KREVEDKO|TEMP

Ну то есть он натурально просто занимается перенаправлением пришедшей откуда-нибудь команды в сеть дочерним модулям. Дочерние же модули, получая команду, разбирают её, и видят: YA_KREVEDKO - наше имя? Нет - пшл на!, ничего писать тебе не буду. Да? ну ок, уговорил, напишу в сеть ответ на запрос, в нашем случае - на запрос TEMP выведу я тебе температуру с датчика.

То есть, простыми словами: команда пришла контроллеру по Wi-Fi, а отправил он её в общую сеть RS485, откуда пришёл ответ, и контроллер отправил ответ по Wi-Fi спрашивающему.

Что будет, если сеть используется одна, например, голимый Wi-Fi как для связи контроллера с дочерними модулями, так и для руления контроллером с помощью смартфона, например? Тогда ситуация будет такая: в общую сеть попадает сообщение CTGET=YA_KREVEDKO|TEMP, отправленное, скажем, софтом смартфона. Понятное дело, что получат его все узлы сети, как контроллер, так и дочерние модули - сеть-то одна! При этом, если модуль не зарегистрирован в контроллере (ну допустим, что ничего не послал модуль контроллеру при первом включении - не захотел, и всё тут), то он просто ответит на команду (раз смог получить без контроллера - значит и ответить сможет, логично чо!). Если же зарегистрирован, как я показал выше, то контроллер сам пошлёт это же сообщение в сеть!

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

Чувствую, что-то в консерватории пошло не так. Буду думать. Хотел вот исходники промежуточные выложить, но, чую - рано

 

Решил проблему со спамом в сети. Для этого введён режим работы класса контроллера - он может работать или как главный контроллер, или как контроллер дочернего модуля. На практике это означает простую вещь: главная коробочка отзывается на команды с префиксом CT, остальные игнорирует. Дочерняя коробочка отзывается на команды с префиксом CD, остальные игнорирует. Как поступать с каждой командой - решает адресат, переданный в первом параметре команды.

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

CDGET=OBAMA_ALABAMA|TEMP

, где упоминание президента СШП и названия штата - это имя модуля. Если же хотим, чтобы запрос пошёл через главный контроллер, то меняем в команде вторую буковку с D на T, и всё - контроллер сам выплюнет в сеть команду для дочернего модуля, а дочерний модуль уже ответит на команду. Иссесно, что при таком раскладе контроллер автоматически будет знать результат выполнения этой команды.

Если же контроллер захочет получать с зарегистрированного дочернего модуля состояние датчиков периодически - да легко, есть модуль LOOP, который это сделает, например, так:

CTSET=LOOP|GET|1000|5|OBAMA_ALABAMA|TEMP

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

CTSET=0|ADD|NAME

Посмотрите на ответы, потом введите

CTGET=NAME|TEMPERATURE|SENSOR1

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

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

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

 

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

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

CTGET=0|PING

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

OK=PONG

Как обычно - поиграть можно через монитор порта, написав приведённую команду и жмакнув Enter. Заодно чуть причесал ответы - теперь нет "+" и "-" перед ответом, только "OK" и "ER" (старое "ERR" усохло на одну букву). Всё равно парсить ответ при необходимости, так зачем лишние символы?

З. Ы. В память Меги пока вмещаюсь Хотя, в принципе, основной костяк уже готов, и можно будет уже переходить к подключению периферии. Stay tuned, друзья!

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

 

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

Добавил костяк модуля опроса температурных датчиков, пока захардкодил рандомные числа. Датчик отзывается на команду

CDGET=TEMP|0

Нолик - это первый датчик, их может быть до четырёх (тоже настраивается в Globals. h). Дописал поддержку установки свойств дочернего модуля - теперь дочерний модуль может послать на нулевой канал контроллера команды, и прописать всё, что он поддерживает. Например, у коробочки есть реле на 8 каналов, один датчик температуры, и эта коробочка хочет зарегистрироваться в контроллере:

CTSET=0|ADD|HOME_MODULE - зарегистрировать модуль в контроллере
CTSET=0|PROP|HOME_MODULE|TEMP_CNT|1 - сообщить, что у него один датчик температуры
CTSET=0|PROP|HOME_MODULE|RELAY_CNT|8 - сообщить, что 8 каналов реле
CTSET=0|PROP|HOME_MODULE|TEMP|0|36,6 - сообщить показания первого датчика
CTSET=0|PROP|HOME_MODULE|RELAY|2|ON - сообщить, что реле 3 включено.

Короче, теперь дочерняя коробочка может сохранять все свои изменения в контроллере. Бонусом получилось ещё следующее: локальный модуль опроса температурных датчиков не даёт прописывать себе свойства по запросу CTSET - ну очевидно же ж, что это правильно - нечего писать, раз мы только опрашиваем датчики. Но! Модуль нулевого канала позволяет таки записать свойства любому зарегистрированному модулю. На нашем примере, если мы хотим принудительно переписать последние запомненные показания с первого датчика, то надо выполнить команду

CTSET=0|PROP|TEMP|TEMP|0|123,15

То есть, другими словами, записать в свойство TEMP модуля TEMP показания 123,15 для датчика с индексом 0. В исходниках, в файле ZeroStreamListener. h - есть описание.

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

Исходники, как обычно, приаттачил. Как только придут датчики температуры - устрою натурные железные испытания с периферией.