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

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

Камень лучше, но и это тоже

 

в отзывах про плату, добрый человек отписал
По сравнению со стандартной Arduino Due обладает рядом преимуществ, иногда делающих выбор в пользу данного товара безальтернативным. Преимущества хорошо описаны продавцом, поэтому остановлюсь на недостатках: 1. Высоковата цена. 2. Отсутствует USB порт для программирования. 3. Перепрошивка более хлопотна - нужно каждый раз нажимать кнопку для стирания старой прошивки. 4. Почему-то контроллер не заработал со стандартным переходником USB-UART, собранном на том же чипе, что и родной. Поэтому лучше сразу покупать плату в комплекте с родным кабелем-переходником. 5. В плату не впаян EEPROM.

 

Если платформу менять, то я все же рекомендую смотреть на ESP8266 NodeMcu и к ней расширитель портов из статьи

 

Так в чем же дело? Портируй, а плату сделаем

 

Немного не так.
Как работать с STM32
1) Приобретаем CZ miniSTM32F103ZE-EK стоимостью 11 $. Это более полная плата и покупать дешевле нет смысла.
2) Приобретаем программатор ST-Link V2 мини STM8 за три копейки.

У нас полный набор для работы.
Скачиваем файл прошивки для работы с Ардуино - generic_boot20_pe2.bin (нам нужен именно этот символы ре2 означают что светодиод подключен к этому порту).
Скачиваем STM32 ST-LINK Utility для загрузки generic_boot20_pe2.bin.
Загружаем загрузчик и все - получаем Maple Mini (Arduino).
Читаем статью https://github.com/stm32duino/wiki/wiki/Getting-Started.
Устанавливаем поддержку STM32 в Arduino IDE.
Перемычки BOOT0 и BOOT1 должны быть установлены в "0".
Скачиваем и устанавливаем DFU driver c сайта https://www.st.com/en/development-tools/stsw-stm32080.html.
Подключаем модуль к USB и включаем модуль. Модуль определяется в сериал как Maple Mini.
Открываем тестовый файл ASCIITable. bin и закомментируем строки 25-27 и 71-73.
Устанавливаем плату "Generetic STM32F103Z series". Upload method "STM32duino bootloader"
Загружаем скетч.
После загрузки получаем сообщение:
-
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=341
Starting download: [#] finished!
error resetting after download: usb_reset: could not reset device, win error: Не удается найти указанный файл.
state (8) = dfuMANIFEST-WAIT-RESET, status (0) = No error condition is present

Done!

Resetting USB to switch back to runtime mode
-
Включаем монитор порта и наслаждаемся выводом текста.

Никаких переключателей для загрузки переключать не нужно.
Все! Можно работать.

Для использования второго USB порта в среде Windows10 нужно переустановить драйвер Prolific USB-to-Serial Comm Port на более древний. Как это сделать прочитайте в http://blog.rchip.ru/ustanovka-drayvera-pl-2303hx-na-windows-8-10/

 

Вопрос на тыщу: кнопка "Пропустить полив на сегодня" нужна в конфигураторе, вебморде, на TFT экране, или нет?

 

Да нужна. К примеру, если стоит в автоматическом режиме полива, желательно иметь возможность не отключать этот режим, а просто пропустит полив на сегодня.

 

Ок, сделаю в трёх описанных местах, для MQTT всё и так уже работает

 

Первое: что-то тут: https://www.forumhouse.ru/posts/22242690/ - четыре плюса всего, не вмещаемся пока в Nextion. После размещения уведомления на сайте gardenboss. ru - был один перевод, на 300 руб. Короче, не хотите вы обнов в виде поддержки семидюймового Nextion Впрочем, немного подождём, если наберётся ещё хотя бы 4 голоса - кину клич на сбор денюх.

Второе: а я вам всё равно дам обновы В конфигуратор, в вебморду, на TFT-экран, на Nextion (как пришпиленный, так и на выносной по RS-485), а также для модуля управления на 7 кнопок - добавлена кнопка/команда "Пропустить полив сегодня".

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

а надо было - вот так:

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

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

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

Итак, что обновилось на гитхабе, для ясности:

1. Основная прошивка для контроллера;
2. Проекты для Nextion (папка Nextion);
3. Проект модуля с кнопками (папка UniversalControlModule);
4. Проект модуля выносного дисплея (папка UniversalRemoteDisplayModule);
5. Конфигуратор (папка SOFT);
6. Вебморда (папка WEB).

Вроде ничего не забыл. Вот видите - такая, казалось бы, мелочь, как введение всего одной кнопки - и допилинг в стольких местах. Легко и быстро, ага Тыжпрограммист, чего тебе стоит

 

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

1. Загрубления показаний (приведение их к какому-нибудь дискрету, типа шага в 100 люкс);
2. Усреднение по последним N показаниям.

Пока вижу так: если настройка "усреднение" активна - то происходит постоянное усреднение по последним N показаниям (например, 10 показаний, интервал чтения с датчиков освещённости у нас и так настраивается). Непосредственно перед тем, как обновить внутреннее состояние, смотрим - активна ли настройка "загрубление". Если она активна - загрубляем.

Думаю, на первый осторожный взгляд - это поможет избавиться от "болтанки"

@olegmak3 - за тобой проверка, как будут обновы

 

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

Итак: см. настройки LIGHT_AVERAGING_ENABLED и LIGHT_HARBORING_ENABLED в конфигурационном файле. Там же рядом - ещё кой какие настройки.

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

Код:

#ifdef LIGHT_AVERAGING_ENABLED
          lum = GetAverageValue(lum,i); // усредняем
        #endif
    
        #ifdef LIGHT_HARBORING_ENABLED
          lum = ApplyHarboring(lum); //загрубляем
        #endif
State.UpdateState(StateLuminosity,i,(void*)&lum); // помещаем в список

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

Алгоритм загрубления:

Код:

long LuminosityModule::ApplyHarboring(long lum)
{
  if(lum == NO_LUMINOSITY_DATA) // нет показаний
    return lum;
  // приводим lum к дискретному шагу
  uint16_t halfStep = LIGHT_HARBORING_STEP/2;
  uint16_t steps = lum/LIGHT_HARBORING_STEP;
  uint16_t remain = lum%LIGHT_HARBORING_STEP;
  if(remain >= halfStep)
    steps++;
  return (steps*LIGHT_HARBORING_STEP);
}

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

Далее, как работает усреднение, тут уже обойдусь без кода, расскажу на пальцах:

1. У нас для каждого датчика есть список, в котором хранится N последних показаний;
2. Если с датчика нет данных - список тут же очищается, т. к. нельзя ничего усреднять;
3. Если кол-во накопленных показаний меньше 4 - возвращаем мгновенное показание. Тут всё просто - поскольку мы отбрасываем граничные значения (минимальное и максимальное), а среднее можно получить минимум по двум показаниям, выходит, что минимальное кол-во показаний для усреднения - 4;
4. Если в списке больше чем настройка LIGHT_AVERAGE_FOR показаний - удаляем самое старое;
5. Затем суммируем все показания в списке, не забыв отдельно сохранить минимальное и максимальное значения, которые потом - отнимаем от общей суммы;
6. Делим полученную сумму на число "кол-во записей в списке минус 2" (поскольку мы откинули минимальное и максимальное) - это и будет наше усреднённое показание.

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

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

Буду признателен за отзыв - как оно на деле: сейчас физически не могу воткнуть датчик освещённости и проверить. Навскидку по арифметике - вроде всё правильно, но мало ли, что называется. Да и на практике проверить - это совсем другое, чем пару раз провести фонариком над датчиком, или проверить правильность применяемых формул расчётами в уме.

Антон Семёнович Шпак сказал мне закончить его знаменитой фразой: "Жду!" Что я и делаю

 

Дима!
Попробую сегодня проверить и отпишусь.
И еще маленько побеспокою- напомню про логи состояния контроллера.
Иногда включается полив в районе 17 часов (вторая половина дня),а настроен на утро.
Вот и возникла необходимость в логах.

 

С логами состояния пока никак, от слова "совсем". В ближайшем будущем не предвидится, сорри.

 

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

 

Прошу прощения, но для контроллера теплицы этот вариант совершенно не подходит. Расширение портов проблему не решает. Как подключать дисплей, датчики. Перелопачивать все библиотеки для подключения относительно сложных устройств. Копеечная экономию, а программисту пол жизни положить. А Serial всего 2 штуки, когда нам и 3 не хватает. I2C совсем не наблюдаю. Убивает наличие TX D1 но не вижу RX D1. Не буду копать глубже, но применения микроконтроллеров для этой задачи меньше 100 выводов не имеет смысла. У DUE значительно больше и то установлено 3-5 расширителей, не считая 4 микросхем управления фрамугами. Обратите внимание на STM32F407 или хотя бы STM32F103. Совместимы с Ардуино, приличная память и неплохое быстродействие.

А Ваш вариант пригоден для небольших выносных устройств. Прошу прощения за возражение.