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

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

Не, можно и на NodeMCU, но смысл сейчас метаться? На данном этапе - это путь в никуда, т. к. портирование всего добра - вещь просто для меня неподъёмная. Да и не надо оно мне лично: более приемлю тот вариант, который сейчас, а именно - модульный. Более того: поскольку я - криворучка, для меня САМЫЙ приемлемый вариант - это использование китайских модулей. Вот если бы со стартом Due не было проблем - была бы вообще песня; но ничего - я как-нибудь доползу до китайской платы, перешью её загрузчик и проверю - если с перешитым будет всё ок - значит, и Due можно юзать.

Ну а потом, даст бог, проверим пока не тестированную адаптацию прошивки под STM32 - и будет вообще шоколад.

Так что, как видите, помимо NodeMCU - есть куча текущих дел, до которых ещё не дошли руки.

 

Планшет с Андроидом? А что сейчас мешает? Поставить туда MQTT Dash и смотреть, что происходит. Ну и - управлять, конечно же. Так что это уже вполне доступно

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

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

 

Кстати сказать: https://github.com/olikraus/u8glib/issues/271

Внезапно оказалось, что hardware SPI не поддерживается для Due в случае использования LCD-крана с контроллером ST7920 и библиотекой u8glib. Это значит, что надо юзать software SPI и другие пины, как и понимаю.

Пытался я, помнится, переползти на u8glib2 (новая библиотека от того же автора). LCD сразу не завёлся, криво рисует. Но это не главное, главное то, что кода и памяти сразу стало жрать больше Плюнул, откатился на u8glib, даже сюда ничего писать не стал, поскольку - не особо-то и актуальна связка 32-битного МК со стареньким графическим экраном, кмк. Честно сказать - я и не тестировал LCD на Due: Александр @promavto упомянул, что он там не работает в настройках по умолчанию (как я понимаю, на моей отладочной плате LCD заведён на аппаратный SPI - поэтому и проблемы, видимо).

Оставлю эту информацию здесь, вдруг кому-то это критично. И, кстати сказать - это ещё один довод в плюсик Nextion: не все гики, и подключить экран по двум проводам сильно проще, чем тонуть в тонне настроек и тонкостей

 

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

Однако, проблема затенения чего-либо - вещь актуальная, кмк. Что если нам просто сделать отдельный модуль, который будет управлять каналами затенения? И будет иметь следующие настройки на канал:

0. Индекс датчика освещённости, привязанный к каналу;
1. Минимальная освещённость, при которой канал - закрывается (тент скатывается);
2. Максимальная освещённость, при которой канал - открывается (тент раскатывается);
3. Время для усреднения, секунд (если показания вышли за пороговые значения и в течение этого времени по усреднению стоят где-то там - то считать, что ситуация устаканилась и можно принимать решение об открытии или закрытии тента).

Можно даже обойтись без отдельного модуля, а просто дописать функционал в модуль освещённости, в конфигуратор и веб-морду. Два канала для двух датчиков - у нас точно можно сделать. И не придётся правила юзать. Или есть тонкие взаимосвязи, что без правил не обойтись?

Что скажете - какие мысли по поводу? Был бы рад что-то сделать с правилами, но пока неясно, как там быть с усреднением - там берутся в расчёт только мгновенные показания, да и для усреднений - оперативка жмёт, ввод любой новой переменной - это её ужатие, т. к. эта переменная - будет для каждого правила. А там и так уже структура одного правила - жирнючая, зарраза.

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

Буду рад любым мыслям по поводу Если дописывать модуль освещённости - то можно туда и нужные зависимости ввести, например, как сделано в модуле полива - состояние пинов, при котором тент - работать не будет вовсе/тут же закроется/тут же откроется. Но для этого надо знать все хотелки, что называется.

 

Последние версии на DUE работают более/менее стабильно. У тебя самый первый вариант. Соберу контроллер на последней разработке платы, отправлю тебе для тестирования.

Но я посмотрел STM32F103ZET6 - характеристики получше чем у DUE и часы работают автономно.
По возможности проверю работу этого контроллера (плата у нас есть) с Ардуино и работу с портами.

 

Было бы здорово, я тогда в обратку бы первую версию отправил - думаю, там есть чего полезного для повторного применения.

Ага, был бы признателен за мал-мала отчёт и инструкцию. А то я, грешным делом, побаиваюсь спалить всё к чертям - всё-таки не 5 копеек плата стоит Надо потихоньку втягиваться.

 

Попробовал поработать с CZ miniSTM32F103ZE EK. Пока глухо. Ранее записал в нее загрузчик Ардуино. Программы записывает, но реакции не вижу. В Serial инфо не выводит. Нужно копать глубже.

 

Сразу не было времени попробовать. Быстренько выбросил это правило и весь разговор.
Даже некогда было глянуть свободную память.
На днях проведу эксперимент и обязательно отпишусь.

Да особых тонкостей я не наблюдал.
Отдельный канал -шикарно.
Можно правилами обойтись, что проще, то и делай.
Ежели отдельный канал, то необходимо следить еще и за температурой внутри теплицы.
Тент, это одна из защит от перегрева.
У меня правилами он открывается-закрывается по температуре.
Плюс после 16-00 открыт принудительно (солнце светит да не греет).
Просто в пасмурную (переменную) погоду жаль терять свет.
Скажем, в теплице +30, тент раскрываем дабы не было критичного перегрева при солнце.
А солнышка-то и нет. И стоит теплица при минимуме света. А если привязать усредненный датчик освещенности, то можно тент скатать с учетом того, что если и случится перегрев, то он будет незначительный, на пару тройку градусов (при переменной облачности), а не фатальный градусов в 10-15 при ясной погоде.
Примерно так, по опыту.
Пару лет назад (особенно весна-осень) тент еще и на ночь (с 23-00 до 5-00) раскатывал.
Какая-никакая,но экономия тепла.
Потом правил стало не хватать,ведь у меня еще два теплых пола, плюс подогрев грядки, две фрамуги и две вентиляции.
Еще недавно приколхозил внутренний блок от кондиционера. Он под потолком теплицы (где разгоняет до 45 и выше, если не принимать дополнительных мер).Через него гоняю циркуляционником воду из емкости для полива (вода за день нагревается градусов до 40, к концу дня немного остывает, т. к. уставки порога включения-выключения кондюка в правилах 28-26,т.е. в конце дня есть возможность забирать какое -никакое тепло из уже нагретой воды).
"Какое-никакое" меня лично устраивает, т. к. блок с пультом был куплен на Авито аж за 1200 рублев, циркуляционник старинный реанимировал. Циркуль- 50-70 ватт, вентилятор в блоке 30.
На радиатор блока тупо настелил кухонные салфетки на которые по дырявой трубочке капает через клапан водичка при низкой влажности.
"В следующем годе"(из анекдота) попробую водичку из колодца закачивать, благо придумал куда деть нагретую-сбрасывать на уличные грядки. Картошка и табак скажут спасибо.
Тысячу извинений за много букв.
Что вижу, о том и пою

 

Заработала! В Serial информацию выводит. Работает и загружает программы нормально. Следующий этап подобрать загрузчик Ардуино. Их три десятка, что оптимально применить изучу. Процедура программирования загрузчиков нормальная.

 

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

 

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

Можно подумать о введении модуля усредненных показаний за определённый период времени. И там уже настраивать, с каких датчиков собирать усреднённые значения. Соответственно, потом можно будет такой датчик из правил опрашивать.

Это, что называется - как вариант решения, оставляющий полную свободу настройки. Один минус - всё это потребует допилинга и правил, и конфигуратора, и вебморды - короче, дело такое себе, не самое приятное.

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

 

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

Но и тут - немного засада: у нас есть универсальные модули, которые могут держать в себе тоже датчики освещённости, т. е. и для них - надо усреднение. Пока вижу такой вариант, навскидку: допустим, у нас в общем зарегистрировано N датчиков освещённости в системе. Тогда при первой настройке модуля освещённости - мы просто прибавляем ещё N датчиков, и там - будут усреднённые значения. На примере: если у нас 4 железных датчика, то для второго железного датчика мгновенные показания будут под индексом 1, а усреднённые - под индексом 5.

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

 

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

С самим усреднением - пока не всё понимаю. Очевидно, что тупо хранить данные с датчиков за последние N минут - не получится: например, у нас периодичность снятия показаний с датчика - 2 секунды. За минуту - 30 показаний, одно показание - 2 байта, т. е. за минуту - минимум 60 байт в оперативке. За пять минут - 300 байт, ни в какие ворота.

Делитесь мыслями - как сделать усреднение, чтобы не отжирать столько оперативки.

 

Один из вариантов сравнивать мгновенные показания с фиксированным рядом значений освещенности. Например ряд значений 100, 500, 1000, 1500, 2000, 2500 и тд. Мгновенное показание сравнивается с 500 и с 1000, к чему ближе, это значение и будет средним

 

А если брать максимальное и минимальное за промежуток времени и с ними работать?