Автоматическая система контроля насосов — необычное решение необычной задачи с микроконтроллером ESP8266. Часть 3. Колдуем над прошивкой.

В предыдущих частях я упоминал о возможных вариантах реализации системы контроля утечек воды на протяженной магистрали, а заодно коснулся конкретной аппаратной реализации. В качестве сердца системы я использую два сенсора наличия переменного тока и микроконтроллер ESP8266 в реализации WeMos D1 Mini Pro. Для того чтобы все заработало, контроллер следует запрограммировать подобающим образом.

В качестве экосистемы, которая более-менее подходит для решения подобных задач, я использовал среду Arduino. Да, ESP8266 может делать куда больше, чем позволяет получить от аппаратной платформы Arduino, но для поставленной задачи большего и не надо. А то, что плата использует лишь 5% от всех своих ресурсов — ничего не поделаешь, стоит она все равно настолько мало, что экономить на микроконтроллере тут просто глупо.

Итак, устройство контроля насосов должно:

  • Отслеживать превышение порога времени работы насоса или насосов по алгоритму скользящего окна и отключать потребителя в случае превышения порога.
  • Собирать статистику в пределах одной сессии и отправлять ее на регулярной основе на сервера ThingSpeak.
  • Быть доступным внутри сети через встроенный web-сервер.

Начнем с самого простого, с Web-сервера.

Web-сервер на ESP8266

Реализация веб-сервера на ESP8266 под Arduino настолько проста и банальна, что в примерах библиотеки ESP8266 есть готовые модули, которые можно скопировать и слегка модифицировав использовать в своих проектах. Благо ESP8266 оборудована встроенным модулем Wi-Fi и позволяет подключаться к беспроводной сети не просто, а очень просто. Кстати, мало кто знает, что под Arduino, имя сети и пароль для подключения к ней, по умолчанию относятся к persistent значениям, т.е. сохраняются в памяти микроконтроллера и при его запуске он автоматически пытается подключить к этой сети, что существенно сокращает время перезапуска и подключения к беспроводной точке доступа.

web-server, WeMos, Sliding Window Failure Control, Excehption, flag:6

Веб-сервер для контроля устройства аварийного отключения насосов

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

Отправляем данные на ThingSpeak

С серверами для хранения и обработки данных от устройств «интернета вещей» я уже сталкивался неоднократно, описывал методики и способы отправки, получения данных с ThingSpeak, на страницах своего блога. Поэтому добавить тут особо нечего. Формируем строку запроса, отправляем ее на сервер. Если все получилось — успокаиваемся, если нет, то повторяем попытку чуть позже.

ThingSpeak, диаграмма, поле, date

Время работы насосов на протяжении нескольких дней

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

Реализация алгоритма скользящего окна

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

В принципе, ресурсов ESP8266 с лихвой хватит для реализации подобной задачи, но уж очень не хотелось связываться с динамическими массивами, да и наверняка подобная задачка может быть решена куда более изящным способом. И как оказалось, решение есть. Для подсчета значений времени работы насосов в рамках окна можно использовать механизм со счетчиками. Ресурсов при этом тратится в разы меньше, чем с массивом, а работает алгоритм почти так же точно.

{ // Line 1 processing
    if (!deBouncerLine1.read())
    { // Sensor detects Usage
        value = 1;
    }
    if (value == 0 & amp; & L1Counter & lt; L1Window)
    {
        L1Counter++;
    }
    if (value == 1 & amp; & L1Counter & gt; 0)
    {
        L1Counter = L1Counter - L1Parts;
    }
    if (L1Counter & lt; 0 || L1Counter == 0)
    {
        L1Counter = 0;
        shutDownLine(1);
    }
} // End of Line 1 processing

Выше я привел кусочек исходного кода, который и отвечает за обработку скользящего окна. Попробую прокомментировать алгоритм и поясню, какой механизм лежит в его основе. Для задания скользящего окна, периода времени, в рамках которого подсчитывается количество единиц времени, в которые работал насос, используется переменная L1Window. В моем случае размерность счетчика приравнена к секундам, а цикл проверки вызывается ежесекундно. L1Counter — текущее значение единиц времени которые осталось работать до превышения порога, измеряется в секундах. L1Parts — константа, на значение которой уменьшается счетчик L1Counter за каждую секунду, когда работает нагрузка. Значение L1Parts задается как делитель от L1Window. Например, если L1Window составляет 3600 секунд, а порог для работы 100 секунд, то L1Parts будет равняться 3600/100=36.

При инициализации переменная L1Counter равна константе L1Window. Если нагрузка выключена, то L1Counter увеличивается на единицу до тех пор, пока значение меньше L1Window. А вот при работающей нагрузке, каждую секунду из L1Counter вычитается L1Parts. Таким образом, уменьшение счетчика происходит быстрее, чем его приращение. А при достижении L1Counter вызывается процедура аварийного отключения нагрузки.

Алгоритм отрабатывает очень быстро, он нетребователен к ресурсам, можно одновременно отслеживать сразу несколько каналов, но у него есть и недостатки. В некоторых случаях, например, при очень рваной нагрузке, алгоритм может ошибаться на несколько единиц времени (секунд). В рамках рассматриваемого устройства подобная ошибка совсем не критична, поэтому применение алгоритма скользящего окна с использованием счетчиков вполне обосновано. Для вызова процедуры со скользящим коном я использовал аппаратные прерывания таймера, доступные для использования в ESP8266.

Что еще?

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

Для реализации вызова таких некритических процедур, как размыкание контактов реле или же публикация информации на ThingSpeak я использую не механизм, основанный на прерываниях, а обычный счетчик, построенный на вызове системной функции millis(). Функция millis() возвращает количество миллисекунд с момента инициализации микроконтроллера. Такая техника позволит избежать коллизий связанных с возможным вызовом прерывания из прерывания, когда вызывается функция для обработки скользящего окна, а посреди ее прерывает функция, связанная с перещелкиванием контактов реле.

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

Выводы

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

Читайте предыдущее: Автоматическая система контроля насосов — необычное решение необычной задачи с микроконтроллером ESP8266. Часть 2. Воплощение в железе.

Читайте далее: Автоматическая система контроля насосов — необычное решение необычной задачи с микроконтроллером ESP8266. Часть 4. Используем OLED-дисплей от Digole.



Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые
Межтекстовые Отзывы
Посмотреть все комментарии