У меня есть дурацкая привычка доводить до конца однажды начатое дело. Почему дурацкая, спросите вы? А потому, что в моём случае это самое желание довести дело до конца может проявляться в совершенно непредсказуемый момент времени. Иногда через год или два после того как я бросил этот проект. Уже и думать забыл про него, ан нет! Вдруг появляется то самое чувство незавершенности и начинает зудеть как расчёсанная реакция Манту.

Проект «Парник» начался в 2016 году как естественная ответная реакция организма на принуждение его к физическому труду. Проще говоря — надо было заставить автоматику делать то, что мне самому было делать лень. А именно:

• открывать и закрывать форточки в парнике при достижении определенных пороговых температур воздуха внутри;
• поливать находящиеся там растения из промежуточного резервуара (бочки);
• следить за уровнем воды в бочке, при опустошении бочки — сигнализировать;
• уметь делать всё вышеперечисленное по команде, поступившей дистанционно (через СМС).

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

В начале лета 2016-го был разработан макет блока управления, чтобы посмотреть как это вообще будет выглядеть и как работать (и будет ли вообще).

• 

• 

Макет был разработан на основе модулей Arduino (плата Arduino Mega, GSM шилд и две платы реле). Я не очень люблю платы Arduino и Atmel в целом. Но в данном случае макет требовалось собрать быстро и максимально дёшево. Пришлось смириться 🙂 В результате получилось что-то вот такое.

• 

• 

Летом того же 2016-го была написана программа для макета, которая обеспечивала открытие/закрытие форточек автоматически и принудительно через СМС, а также отчет о состоянии в СМС (температура/влажность внутри, напряжение питания). Питалась эта система от аккумулятора 12 В. Зарядка предполагалась вручную. Однако, исправление багов прошивки и отладка затянулись и не позволили протестировать систему в «боевых» условиях — лето закончилось. Однако, сама концепция устройства была признана рабочей.

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

• 

• 

К слову, на новой плате всё же был оставлен посадочный разъем под ардуиновские шилды. Так оказалось удобнее — на это место сажается либо GSM шилд либо WiFi шилд (была также версия с XBee модулем) в зависимости от требований к системе. В таком вот виде этот блок и был установлен в систему.

• 

• 

• 

Это, собственно, была только история вопроса. А теперь к главному — что не так то?! Вроде всё закончено и функционирует. Система отработала два сезона (первый год с GSM-модулем, второй с Wi-Fi и передачей на данных на локальный сервер).

В период опытной эксплуатации был выявлен ряд проблем с системой:

• Датчики. В системе использовались датчики DHT22 для измерения температуры и влажности воздуха внутри и снаружи (на всякий случай) парника. За два года эксплуатации вышли из строя 2 датчика. Это много. Надежность DHT22 оставляет желать лучшего. Их надо менять на что-то другое.
• И снова датчики. Вне зависимости от типа, датчики должны быть цифровыми (ибо таскать аналоговые сигналы по несколько метров себе дороже). А цифровые датчики имеют возможность зависать, что и было не раз продемонстрировано датчиками DHT22. Значит, надо иметь штатную возможность снимать и подавать на них питание в случае ошибки без перезапуска всей системы.
• Выяснилось, что система не защищена от КЗ или повышенного энергопотребления внешних устройств. Последний из вышедших из строя датчиков образовал контур с пониженным сопротивлением и высаживал АКБ за пару часов.
• Корпус блока управления. Большой и железный. Большой мешает установке на раму парника (весьма хлипкую), а железный мешает работе беспроводных модулей — приходится вытаскивать антенны наружу. Проблему с габаритами можно решить интегрировав зарядное устройство в плату управления.
• Стоимость комплектующих. Предыдущая плата управления была разработана под те компоненты, которые у меня были в наличии и всего было смонтировано две платы. Как выяснилось, при необходимости расширить производство компоненты будет не так просто достать и стоимость у них соответствующая. Необходимо оптимизировать стоимость.
• Низкая технологичность отдельных узлов. Для уменьшения стоимости датчики были сделаны из покупных модулей, соединенных объемным монтажом. Кроме того, соединялись датчики с кабелем при помощи пайки (только соединение с блоком управления было на пружинных клеммниках). Поэтому техническое обслуживание системы превращалось в сущий ад. Снять датчик при таком раскладе не представлялось возможным ибо кабель уже просунут через всевозможные отверстия и закреплен где только можно. Попытка же перепаять сломанный DHT22 на месте (стоя внутри засаженного парника посреди помидоров) — это занятие для сильных духом.
• Небольшое количество каналов управления. Их сейчас хватает, но нет резерва, а со временем всегда возникает желание что-нибудь ещё добавить. Например, досветку или обогрев или принудительную вентиляцию. Да мало ли что в голову взбредёт.
• Отсутствие местного ручного управления. Иногда нужно находясь рядом с парником отдать ему какую-то команду (перейти в Safe-mode, принудительный полив и т.д.). Сейчас для этого приходится искать какое-нибудь устройство (ноутбук/телефон). Это очень неудобно. Необходимы кнопки на самом блоке управления.
• Отсутствие индикации. Требуется индикация двух возможных ситуаций — «авария» и «требуется вмешательство пользователя». Самый распространенный вариант последнего — это пустая поливная бочка.

Итак, перед нами новая (на самом деле старая) задача, и сейчас самое время ей заняться. Казалось бы до весны ещё куча времени, но если учесть что весь объем работ будет выполняться одним человеком — то можно ещё и не успеть). Для того, чтобы правильно спланировать работу был использован OpenProject. Давно хотел его попробовать вместо Redmine, которым пользуюсь уже относительно давно. Вот так выглядит график первого этапа работ.

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