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

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

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

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

По прежнему остаюсь на своей позиции - переключатель по температуре в виде железки.

З. Ы. Примеры кода по получению температуры с того или иного датчика - я дам, не вопрос. Но - не более того.

 

Наконец то удалось протестировать. Сообщаю результаты.

1. Китаец прислал разные датчики. 3 штуки 5-24 В (реально работают даже от 3 В) и 2 штуки на 24 В (работают от 16 В). Поэтому пока тестирую с тремя датчиками и проводочками для подтяжки нужных контактов.


2.
Что сделано:
Последовательно "наполняем" бак.
Самый нижний датчик показывает "Есть вода", остальные датчики сухие - в логе и на дисплее 20%
2 нижних датчика показывают "есть вода", остальные датчики сухие - в логе и на дисплее 60% (а должно быть 40%)
3 нижних датчика показывают "есть вода", остальные датчики сухие - на дисплее и в логе 60%

3. Если из экрана с кнопками бака войти в меню "ОПЦИИ" или "УПРАВЛЕНИЕ", а потом выйти обратно, то шрифт в инфобоксе меняется на smallFont. На фото прошивка версии 06-10-20, но в версии 30-10-20 этот глюк сохраняется. Перелистывание меню влево-вправо исправляет шрифт.

Подозреваю, что дело либо в отрисовке номера версии (после отрисовки шрифт по-умолчанию остается на smallFont.
Такая чехарда со шрифтами повторяется на экране со статусами фрамуг, полива и досветки

4. Если довести систему до ошибки наполнения бака (по времени, статус на экране: "Е наполнения"), то сбиваются проценты наполнения бака. То есть, если зарегистрирована ошибка наполнения, и самый нижний датчик показывает "есть вода", а остальные датчики в положении "сухо", то на экране и в логах уровень отображается как 33%, хотя должно быть 20% (установлено и прописано 5 датчиков). Если продолжать наполнение бака, то при 3 "мокрых" датчиках наполнение становится 100% (а должно быть 60%)
Лог в файле ошибка1.txt

5. Последовательно уменьшаем уровень воды в баке. Когда осушается последний (самый нижний) датчик, система начинает бешено щелкать клапаном наполнения бака. Так будет продолжаться, пока самый нижний датчик не покажет состояние "есть вода".
лог в файле ошибка0.txt

 

По-моему, можно даже проще. В модуле ВЕНТИЛЯЦИИ уже есть привязка к температуре, даже с гистерезисом. Да, там нельзя выбрать температуру процессора в качестве термодатчика, но ведь можно повесить еще один датчик DS18B20 в шкафу.

 

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

 

Срабатывает условие:

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

 

Строка 695 прошивки, всё сделано согласно вашему ТЗ:

При этом количество РАБОЧИХ датчиков - уменьшается, соответственно, и процент наполнения учитывается только ПО РАБОЧИМ датчикам. Могу переделать, но это, имхо, неправильно.

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

 

Давайте разбираться. Вот код по подсчёту процентов наполнения бака:

Код:

uint8_t getFillStatus() // возвращает процент заполнения (0-100%)
{
  float cnt = getCountOfWorkingSensors(); // количество рабочих датчиков
  // считаем, что все датчики исправны и расположены равномерно по баку.
  // рассчитываем, сколько датчиков показывают воду, прерываемся на первом, кто воду не показывает

  uint16_t hasWater = 0;

  for(uint8_t i=criticalLevelSensorIndex;i<=fullLevelSensorIndex;i++)
  {
    if(levelSensorsState[i])
    {
      hasWater++;
    }
    else
    {
      break;
    }
  } // for

  // пропорция
  // cnt = 100%
  // hasWater = x%
  // x = (hasWater*100)/cnt;
  float f1 = hasWater;
  f1*=100;

  float result = f1/cnt;

  return roundf(result);
}

Как видите, всё предельно просто: есть общее количество РАБОЧИХ на данный момент датчиков -getCountOfWorkingSensors(). Есть индекс датчика критического уровня, и индекс датчика верхнего уровня бака. Проходим по всем датчикам между этими двумя индексами (они растут навстречу друг другу, если датчики выходят из строя), и смотрим - если датчик показывает "есть вода" - плюсуем количество датчиков с водой.

Потом - простейшая пропорция. Проверяем: допустим, getCountOfWorkingSensors() вернула нам 3 рабочих датчика. Допустим, в hasWater мы получили 1, т. е. только один датчик показывает воду. В переменной f1 будет 1*100 = 100, затем делим f1/cnt, т. е. 100/3, и получаем 33%, всё верно.

Допустим, все датчики рабочие, 5 штук. Два из них показывают, что есть вода. Получаем 200/5 = 40%, всё верно.

Допустим, все датчики рабочие, 5 штук. Три из них показывают, что есть вода. Получаем 300/5 = 60%, всё верно.

Думаю, у вас проблема с аппаратной частью. Надо исключить этот вариант, как минимум. И кстати - из кода видно, что прерывание цикла происходит на первом датчике, который воду НЕ показывает. То есть если аппаратная часть работает абы как, вразнобой - то и результат будет получаться как бы вразнобой

 

Обновления

Обновил прошивку на гитхабе, пофиксил проблему с размером шрифта на экране ожидания (спасибо Максиму @StormChaser за багрепорт ).

 

@StormChaser - что я думаю: а нет ли дребезга у датчиков? Может, вам добавить побольше отладочной информации в прошивку, чтобы было понятно, что пошагово происходит?

Если у датчиков есть дребезг - то это может, теоретически, сослужить хреновенькую службу. К тому же - у нас есть детектирование ошибок, и уменьшение кол-ва рабочих датчиков, с переназначением их функций другим.

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

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

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

Пишите

Правка: понял причину одной ошибки, поправлю, выложу, и отпишусь.

 

Любой, который выдаёт 0 или 1 на выходе.

 

@StormChaser - Максим, перекачайте проект с гитхаба: я обновил прошивку WaterTankModule, убрал интервал обновления датчиков, теперь они обновляются при каждом проходе loop. Там была логическая ошибка именно из-за периодического обновления - возникала ситуация, когда мы работали с невалидными данными, не отражающими актуальное состояние датчиков (грубо говоря - попадание в ветку ожидания наполнения бака в момент МЕЖДУ обновлениями показаний с датчиков).

Просьба отписаться, как прошло тестирование новой прошивки

 

Теоретически, у этого датчика на выходе транзистор. Проверено мультиметром - если вода есть, то на выходе низкий уровень, если воды нет - высокий.
2 "верхних" датчика у меня отсутствуют, вместо них проводочки (к земле и питанию соответственно). Датчики подключены разъемами JST-XH к промежуточной плате (чтобы развести землю и питание на 5 датчиков), далее через винтовые контакты к универсальному модулю. Плата пропаяна (не макетка со штырьками)
=ЗДЕСЬ БУДЕТ ФОТО, КОГДА ДОБЕРУСЬ ДО ДОМА=
В выходные притащу осциллограф с дачи, тогда вопрос с дребезгом контактов можно будет закрыть.

Идея здравая, я тоже думал над этим вопросом. Дело в том, что в момент наполнения бака могут быть брызги или волны, которые могут вызывать недостоверные срабатывания датчиков. У меня, например, наполнение бака сделано сверху. Согласен, что логичнее наполнять снизу, как в сливном бачке в туалете. Но в момент сверления дырок в баке этой мысли еще не было.

Понял, разобрался. Тут я поспешил. Код не посмотрел, скорей полез подключать провода и писать отчеты . Предлагаю добавить это объяснение в комментарии в WaterTankModule.ino

Нет, датчики емкостные. Но принцип именно такой, как Вы написали.
https://www.amazon.com/Non-Contact-Liquid-Level-Sensor/dp/B07RZ8FLW8

 

Скачал и прошил версию 10-11-20

1. Шрифты работают нормально
2. Настройки уровней датчиков и времени наполнения бака через конфигуратор работают нормально
3. Ошибка с неправильным подсчетом процентов

устранена. Причина была не в софте и не в контактах. Я криво прописал LEVEL_SENSORS_PINS. Прошу прощения.

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

5. В меню "УПРАВЛЕНИЕ" нет иконок для некоторых кнопок. Я тут иконки дорисовал, выставляю на суд общественности.
Контроль СО2
Двери
Спринклеры

 

Рад, что с модулем бака всё хорошо. По поводу иконок - надо их встроить. Отправьте их мне на почту, постараюсь внедрить