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

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

На сервис gardenboss. ru, а также в прошивку - добавлена возможность выставления двух новых типов команд: "запустить сценарий" и "остановить сценарий". Теперь сценариями можно рулить и через gardenboss. ru

А я пока думаю, как всё-таки припилить ишшо один экранчик со сценариями для LCD - ну не отпускает мну это дело

 

И так...
Лабораторная работа.
1. LIGHT_AVERAGE=20
LIGHT_HARBORING_STEP=200.
Освещенность от 0 до 2000 (лампа, вкл-выкл).
От минимума до максимума показания датчика нарастают (спадают) за 1 минуту с шагом 200.
2. LIGHT_AVERAGE=20
LIGHT_HARBORING_STEP=50.
Освещенность от 200 до 4200 (лампа, вкл-выкл).
От минимума до максимума показания датчика нарастают (спадают) за 1 минуту с шагом 50-500 (имхо,из-за того, что лампа в режиме вкл-выкл.)
Свободной памяти (работа через вебморду) 1078 +/- 50 байт.
3. LIGHT_AVERAGE=50
LIGHT_HARBORING_STEP=50.
Освещенность от 200 до 4200 (лампа, вкл-выкл).
От минимума до максимума показания датчика нарастают (спадают) за 2,5 минуты.
Свободной памяти (работа через вебморду) 946 +/- 50 байт.
4. То же, что и 3, но время опроса модуля освещенности увеличено до 10 секунд.
От минимума до максимума показания датчика нарастают (спадают) за 7,5 минут.
5. Вебморду выключил, подключился через кофигуратор.
Свободной памяти стало примерно 1280 +/- 50 байт.
Итого. РАБОТАЕТ! (Имхо).
Натурных испытаний не проводил, т. к. " погоды стояли ясные, на небе ни облачка".
КМК. Теперь осталось определить для себя насколько быстро наступит критический перегрев теплицы при ясном небе и скатанном тенте, и уже под это время подстроить опрос модуля освещенности и величину LIGHT_AVERAGE. По расходу памяти примерные цифры привел. Также необходимо учесть, что реальном солнце время изменения показаний датчика освещенности будет больше озвученных цифр, т. к тучки в режиме вкл-выкл не ходят.
Надо или нет улучшать алгоритм покажут натурные испытания.
Кмк, этого будет достаточно.
Конец лабораторной работы

 

Обновил прошивку, для LCD-дисплея добавил экранчик "Сценарии" Выбираем экран листанием вкладок с помощью энкодера (короче, всё как обычно), кликаем кнопкой энкодера, попадаем внутрь экрана - название сценария будет выделено. Крутим энкодером - сценарии листаются. Кликаем ещё раз - попадаем на кнопку "ПУСК" или "СТОП". Крутим энкодер там - сценарий запускается или останавливается.

Протестировал - работает. Ну а дальше - будем посмотреть, надеюсь, новых багов не добавил

 

Олег, огромное спасибо! Как я и говорил - будем подбирать, что к чему: практика - критерий истины, как говорится

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

Конечно, лучшим вариантом будет, в данном конкретном случае - это переход на STM32, мы это обязательно сделаем со временем

 

Понимаю прекрасно.
Как вариант, будет два набора правил- летние и зимние. Управление тремя теплыми полами много съедает.
Пока не разбирался со сценариями. М. б. с их помощью удастся сэкономить кол-во правил.

 

Посидел тут множко ночью - и наваял софт для визуального создания/редактирования сценариев. Называется SceneCreator. exe, лежит в папке SOFT архива с проектом.

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

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

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

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

 

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

 

Ну конечно.

При включенном усреднении мгновенных данных нет - во внутреннее состояние попадают уже усреднённые данные.

Нет, там простая арифметика.

Там просто отбрасываются два значения, всё. Вот ВЕСЬ код, который усредняет:

Код:

long LuminosityModule::GetAverageValue(long lum,uint8_t sensorIndex)
{
  if(lum != NO_LUMINOSITY_DATA) // помещаем в список, только если есть показания с датчика
  {
    averageLists[sensorIndex].push_back(lum);
  }
  else
  {
     // с датчика нет показаний, надо очистить список усреднения, поскольку мы не можем усреднять
     // актуальные значения с отсутствием показаний с датчика: как только показания с него пропадут,
     // мы тут же должны сигнализировать об этом, и не применять никакого усреднения.
     averageLists[sensorIndex].clear();
     return lum;
  }

  // мы отбрасываем 2 граничных показания, а среднее можно искать только минимум по двум показаниям.
  // также, если с датчика постоянно не будет данных - список будет пуст, и мы просто вернём переданное значение.
  if(averageLists[sensorIndex].size() < 4)
    return lum;

  // удаляем элементы, пока кол-во не будет равно кол-ву шагов
  if(averageLists[sensorIndex].size() > LIGHT_AVERAGE_FOR)
  {
    // у нас на один элемент больше, чем надо, удаляем его из списка
    for(size_t i=1;i<averageLists[sensorIndex].size();i++)
    {
      averageLists[sensorIndex][i-1] = averageLists[sensorIndex][i];
    }
    averageLists[sensorIndex].pop();
  } // if

  // у нас есть список из N элементов, и их минимум 4. Надо найти там минимальное и максимальное значение,
  // и не учитывать их при расчётах.
  long minVal = 0;
  long maxVal = 0;
  uint32_t avg = 0;
  size_t steps = averageLists[sensorIndex].size();

  for(size_t i=0;i<steps;i++)
  {
    long curVal = averageLists[sensorIndex][i];
 
    maxVal = max(maxVal,curVal);
 
    if(i == 0)
      minVal = curVal;
    else
      minVal = min(minVal,curVal);

    avg += curVal;
  } // for

  // отнимаем минимальное и максимальное значение
  avg -= minVal;
  avg -= maxVal;

  // считаем среднее
  long result = avg/(steps-2); // отнимаем 2, поскольку мы отбросили граничные значения

  // готово, возвращаем
  return result;

}

Как видно, там ничего космического нет.

Вообще странно: мы ввели усреднения для того, чтобы сгладить график. А теперь смущаемся факту, что

Это как раз тот эффект, которого надо было достичь.

 

@olegmak3 - единственное требование, исходя из кода усреднения, это - чтобы настройка
LIGHT_AVERAGE_FOR была не меньше 4, поскольку мы отбрасываем два показания. Далее, на пальцах, по шагам алгоритма:

1. С датчика нет данных - очищаем список усреднения для датчика, выходим;
2. С датчика есть данные - помещаем в список;
3. Если в списке меньше 4-х показаний - возвращаем мгновенное показание;
4. Удаляем самое старое показание сразу, как только в списке будет значений больше, чем LIGHT_AVERAGE_FOR;
5. Пробегаемся по списку, суммируем все показания, попутно - запоминая самое большое и самое маленькое показание в списке;
6. Отнимаем от суммы максимальное и минимальное показание;
7. Делим сумму на кол-во показаний в списке минус 2;
8. Возвращаем результат.

Далее, на примере настройки LIGHT_AVERAGE_FOR в 4:

1. Показания датчика - 100. В списке - []. Помещаем туда, возвращаем 100, выходим;
2. На датчике - 200, в списке [100]. Запоминаем, возвращаем 200, выходим;
3. На датчике - 100, в списке [100,200]. Запоминаем, возвращаем 100, выходим;
4. На датчике - 500, в списке [100,200,100]. Запоминаем. В списке [100,200,100,500], т. е. 4 показания. Далее - считаем сумму, она получается 100+200+100+500 = 900. Минимальное показание - 100, максимальное - 500, от 900 отнимаем 100 и 500 - получаем 300. Далее - делим 300 на (4-2) - получаем 150. Это и будет среднее за 4 показания.

Всё правильно? Продолжим. Допустим, при тех же вводных, у нас LIGHT_AVERAGE_FOR = 5, в списке [100,200,100,500], и пришло показание 500 - в списке оказывается [100,200,100,500,500]. Суммируем, получаем 1400. Отбрасываем мин и макс, получаем (1400 - 100 - 500 = 800). Делим на (5-2) = 800/3 = 266. Это и будет средним за 5 показаний.

Продолжаем. Допустим, пришло шестое показание - 80, при LIGHT_AVERAGE_FOR = 5 и списке [100,200,100,500,500]. Помещаем в список, получаем [100,200,100,500,500,80]. Потом смотрим - в списке 6 элементов, что больше максимальной настройки для усреднения. Отбрасываем самый старый, получаем список [200,100,500,500,80]. Далее арифметика: (200+100+500+500+80) = 1380; 1380 - 80 - 500 = 800; 800/(5-2) = 266. Это и будет средним.

Как видно из эмпирических примеров, при резком колебании двух последних показаний НА ПОРЯДОК (было 500, стало - 80) - НЕ происходит резкого изменения усреднённого значения. ЧТД, собственно.

Далее: допустим, пришло ещё раз 80, список стал [100,500,500,80, 80]. По формуле получаем: (100 + 500 + 500 + 80 + 80) = 1260; 1260 - 500 - 80 = 680; 680/(5-2) = 226. Налицо - ПЛАВНОЕ падение усреднённого значения. Оно и дальше будет плавно падать, если последующие показания будут одного порядка, и будет падать до тех пор, пока бОльшие показания - не вытеснятся из списка. Затем - наступит некое "насыщение", и усреднённые показания будут находится где-то около одной точки.

Можно сравнить график по исходным показаниям, без усреднения, он будет описан точками [100,200,100,500,500,80,80], и график усреднённых значений, он будет описан точками [100,200,100,150,266,266,226] - кмк, разница - разительная.

Вот наглядная демонстрация из Excel двух рядов, по второму видно, что он - сглаженный:



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

 

В свете введения сценариев, кмк, стало не хватать возможности запускать/останавливать сценарий из правил. Как думаете - надо или нет?

 

Тогда объясни темному, откуда в пасмурный день такое ?
В16-00 1400люкс, в 16-10 уже 500, и в 16-16 тоже 500.
При:
LUMINOSITY_UPDATE_INTERVAL 10000
LIGHT_AVERAGE_FOR 50
LIGHT_HARBORING_STEP 50 в прошивке.
Чуть больше 8 минут (50х10000/60000) получение 50 значений.
Это с какой силой в пасмурный день нужно было светануть, чтобы вызвать такие изменения?
Чего недопонимаю?

Завтра скачаю логи из контроллера и гляну там. Сравню характер изменения с архивами (благо за несколько лет скопились).

 

Обновление прошивки, ниже приведён список изменений:

1. В прошивку контроллера добавлена возможность рулить сценариями из правил (останавливать/запускать по условиям);
2. В конфигураторе - добавлена возможность выставлять действия "Запустить/остановить сценарий" при добавлении/редактировании правила;
3. В веб-интерфейсе - добавлена возможность выставлять действия "Запустить/остановить сценарий" при добавлении/редактировании правила, а также добавлено управление сценариями на страницу "Показания".

 

Первое: я уже писал, что ПОКА показаний МЕНЬШЕ 4-х (не усредняется на меньшем кол-ве, и всё - арифметика) - в состояние попадает МГНОВЕННОЕ значение. Поймали 1400 люкс в этот момент - ОНО БУДЕТ в состоянии контроллера. Если в этот момент надо отправить данные на сайт - что отправится? Правильно - отправится МГНОВЕННОЕ показание, т. е. 1400 люкс. Так совпало, что называется.

Давай смотреть: обновление показаний с датчика - раз в 10 секунд, за минуту - 6 измерений, за 10 минут - 60 измерений, правильно? Теперь смотри, какая фишка: где-то В НАЧАЛЕ - сильно светанули, светили какое-то время, ЗАВЕДОМО БОЛЬШЕЕ 10 секунд. Накопленных для усреднения данных - мало, гораздо меньше 50, поэтому что? Правильно, получаем на выходе достаточно высокое усреднённое значение.

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

Давай ещё раз, можем разложить всё это дело на пальцах. Ниже - списки, и выведенное усреднённое значение через "=>". Для простоты подсчётов - оперирую удобными числами, но сути это не меняет.

[1000] => 1000
[1000,1000] => 1000
[1000,1000,1000] => 1000
[1000,1000,1000,2000] => 1000
[1000,1000,1000,2000,3000] => 1333
[1000,1000,1000,2000,3000,10000] => 1750
[1000,1000,1000,2000,3000,10000,100] => 1600
[1000,1000,1000,2000,3000,10000,100,100] => 1350
[1000,1000,1000,2000,3000,10000,100,100,100] => 1171

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

Смысла юзать 50 шагов для усреднения - не вижу, кстати. Лучше поставить интервал обновления данных с датчика на побольше. Для 50 шагов - много оперативки жрётся.

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

Если ты предпочитаешь, чтобы, пока не накопится 4 показания, в состоянии контроллера было для датчика "нет данных", то можно и такую настройку прикрутить. Но - это неверно, пмсм: усреднение - это просто сглаживание графика, при этом показания с датчика идут постоянно. И график, ПО МЕРЕ накопления статистики - сглаживается.

Зачем такое маленькое загрубление? 50 люкс - это ооочень мало для загрубления, кмк. Если хочешь избавиться от "болтанки", то лучше шаг загрубления сделать побольше, а кол-во шагов для усреднения - можно и поменьше.

Короче, эти три настройки - как некий ПИД, их надо подбирать

 

@olegmak3 - в принципе, есть ещё одна, более простая возможность сгладить график: для текущего значения освещённости брать среднее арифметическое между текущим - и прошлым значением, и всё. Например, если последнее значение было - 1000 люкс, а текущее - 2000 люкс, то в состояние попадёт 1500 люкс. Если 2000 люкс держится далее - в следующее состояние попадёт уже 1750 люкс и т. д.

Но такой подход - не обеспечит защиту от резких изменений: например, если последнее значение было 1000 люкс, а текущее - 100, то вычисленное будет - 550, что уже в два раза меньше, чем последнее, т. е. - налицо всё равно резкое изменение тренда.

Но не предложить - я не мог

 

А если просто цифровой фильтр? H1 = 0.99 * H1 + 0.01 * Y1; /цифровой фильтр