Контроллер для теплицы на Arduino - 2

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

Время разбрасывать камни и время собирать камни. Прошло 10 мес., как забросил разработки. Тогда меня хватило всего на пару месяцев.
Однако стройки на даче подошли к концу, на этот год уже никаких больших планов нет - мелкие доделки и рутина на огроде. Видимо, настало время заняться, наконец, внедрением автоматики.
На чём я там остановился? - Ага, я всё никак не доделаю локальный мониторинг температуры и влажности, без интернета.
Пробовал написать HTML-CSS-JS-рисовальшик диаграммы на компьютере, получилось вот так:

Картинка области оптимального климата на диаграмме стала отображаться, но как передавать данные с датчиков в программу на компьютере - ни в зуб ногой.
Стал разбираться, как это работало в прежнем скетче, в котором диаграмма строилась из интернета.
Оказалось, в ней всё строилось в контроллере, а в компьютер передавалась уже готовая программа, но я этого не понимал потому, что использовал в качестве основы чужую готовую программу.
Решил, что всё строить на контроллере для меня будет проще. Но теперь уже вся программа визуализации былы своя, в локальном варианте и я использовал файловую систему ESP8266 - LittleFS. - Ура, картинку вставить удалось.
Всё, на этом мои потуги в начале апреля прошлого года закончились. Пару недель назад начал вспоминать и двигаться дальше.

Файл библиотеки визуализации Chart. js также встроил в ESP без труда, всё считывается. В итоге воспроизвёл эту же диаграмму, только теперь скетч, файл-рисовальщик диаграммы на HTML+CSS+JS, изображение и библиотека Chart. js - всё своё и находится внутри ESP.
Однако по картинке видно, что данные с датчиков липовые - все точки расположены на линиях сетки. Я просто вставил в файл JS фиксированные координаты, т. е. передавать данные всё равно нужно, вот на этом моменте сейчас и сижу.

Дело в том, что эта проблема для меня абсолютно новая. Начал знакомиться с тем, какие форматы передачи существуют вообще. Распространённых форматов, которые я нашёл, оказалось совсем немного: MQTT, WebSocket, XML и Json.
MQTT, WebSocket первыми отпали - слишком избыточны для моих скромных целей. XML - устарела, так что остался формат Json - с ним и знакомлюсь сейчас.

Однако остался вопрос: в старой то программе у меня как всё передавалось? Сколько ни рассматривал её, никаких форматов передачи в ней не было вообще. Наконец, понял, как она это делала.
Весь файл передачи был завёрнут в строку и, когда рисование подходило к моменту передачи данных с датчиков, строка закрывалась и включался цикл перебора массивов. Данные по указателю выбирались, снова включалась строка, упаковывались в JS формат и тут же передавались браузеру, затем строка снова прерывалась, счётчик увеличивался на единицу, выбирались новые значения датчиков... и так до конца массивов. Далее строка снова включалась и передавала остаток файла JS.

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

 

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

 

Всё, диаграмма готова и отражает реальные данные с датчика температуры/влажности Si7021:



Поскольку испытываю систему дома, температура и влажность стабильные: влажность примерно 16%, а температура - 25°С. Изменение показаний температуры и влажности имитировал прикосновением пальцем к датчику - видно, как показания сразу начинает меняться - бежать вправо и вверх, ближе к области оптимального климата, а затем, как убираю палец, постепенно возвращаются к прежним значениям.
Правда это у меня работало ещё год назад, но тогда для построения диаграммы использовалась библиотека GoogleCharts. JS с облака, т. е. без интернета она не работала, и мне никак не удавалось встроить в диаграмму картинку - область оптимального климата.
Этот вариант интернета не требует, а значит не требуется оборудование, антенна и текущие расходы.

Раньше я купил, не разобравшись, модуль NodeMCU, хотя в продаже были модули Wemos, функционально идентичные, но в 2 раза меньших размеров и такое же количество выводов. Прикупил парочку и ещё модуль ESP-01, который ещё в 2 раза меньше.



Правда у модуля ESP-01 всего 2 вывода, но для данной системы мониторинга температуры и влажности этого достаточно. Рядом RTC - модуль реального времени.
Собираюсь на ESP-01 и на RTC сделать атономную систему мониторинга, которая будет работать от батарейки и передавать данные по Wi-Fi исполнительным механизмам, которые тоже можно будет собрать на ESP-01. Таким образом можно будет избавиться от паутины проводов в системе управления для теплицы.
Время, правда, пока на диаграмме, как видите, отсутствует, но я сделаю, чтобы оно показывало время появления каждой точки на экране при наведении курсора на эту точку, хотя, честно говоря, это не так уж и нужно. Пока время у меня синхронизируется по NPM.

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

 

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



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

Теперь об исполнительных механизмах (ИМ). несмотря на заголовок, состояние ИМ на диаграмму пока не выводится, так что устройство работает чисто как метеостанция. В принципе, оно даже в таком варианте уже очень полезно и дома и на даче. Размеры очень маленькие, токопотребление тоже, так что оно может работать от батареек и ему ни кнопки, ни дисплей не нужны, потому что оно передаёт данные на диаграмму компьютера или смартфона через Wi-Fi.

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

Но вообще, я намерен проводить эксперименты с ИМ, управляемыми от этого контроллера - форточки, двери, вентиляторы, обогреватели, рекуператоры, ПЛЭНы, грунтовые теплообменники, распылители влаги (фоггеры).

 

Новая проблема.
Казалось бы уже всё заработало: Отключаю интернет - прошивка работает, информация с контроллера передаётся и по кабелю USB и через Wi-Fi. Диаграмма выводится - температура, влажность.
Осталось взять старый компьютер, отнести на дачу и можно работать в автономном режиме. Но на старом компе стоит 32-разрядная Win-10, а система программирования Arduino IDE - 64-разрядная.
Т. е. компьютер очень старый и еле шевелится. Решил накатить укороченный 64bit-ный образ Win-10. В общем он встал и стал работать очень даже шустро, только что цвета на экране тёмные. Не стал с этим разбираться, ведь мне не пейзажи разглядывать, а только с Arduino IDE работать, при этом я выбираю тёмное решение, да диаграмму - она тоже отображается нормально.
Вроде и Arduino IDE 64-бит тоже встала нормально, компилируется, загружается, но ... сетевой адрес после загрузки не появляется.
3 дня бился - результат- 0. Уж купил бы простейший новый мини-ПК, они есть от 5,5 тыр., но сомнения одолевают - причина то в чём? Может, роутер? Он тоже старый, но до установки нового работал с действующим ПК, диаграмма, Wi-Fi - всё показывало. Непонятки...
В общем, надоело, надо переключиться - сезон начался, на даче есть работа, как снова потянет разбираться - продолжу.

 

А эта система работает по локальной сети или связана с сторонними серверами? А то моя tuya тоже перестала графики отображать. Связываю это с тем что в войне с Ираном были повреждены серверы амазон, который вроде как связан с этой tuya

 

Нет, до локальной сети ещё далеко. Пока один контроллер и то не работает со старым компьютером и старым роутером. И ещё проблема со временем. Пока получаю его с сервера NTP, но если хочу работать без интернета, то нужно вместо сетевого времени использовать своё - RTC, вот на фото датчик температуры/влажности, контроллер и RTC (тот, что с батарейкой).



Если бы не RTC, то всё вообще бы в спичечном коробке уместилось, вот когда сеть сделаю, то RTC нужен будет только один, другие будут синхронизировать время через Wi-Fi от него.
Так что провода не нужно будет тянуть к исполнительным механизмам - приводам форточек, фоггерам, ПЛЭНам, кабелям обогрева грунта и пр. К примеру, ставлю привод форточки и рядом контроллер в маленькой коробочке, который получает по Wi-Fi команду: приоткрыть, прикрыть форточку.

 

Продолжил разбираться, почему на старом компьютере нет загрузки по OTA (по Wi-Fi, без проводов). Разбирался дня три и пришёл к выводу, что наверное накатил кривой образ винды. Почитал отзывы на этот образ и встретил жалобу, что Wi-Fi не работает - точно тоже, что и у меня. Ещё изображение на экране было тёмным.
Вчера накатил другой образ - изображение стало нормальным, цветопередача тоже исправилась. Диаграмма стала грузиться, но только при подключении к новому роутеру, со старым опять же пропадает Wi-Fi. Причём, роутер то обнаруживает ESP-иху, то она отпадает. Прописал её в роутере насильно - исчезать перестала, но связи по беспроводной сети всё равно нет.
Но раньше этот роутер был подключен к новому компьютеру и прошивку он загружал. Правда после этого уже и версию Arduino IDE я не раз обновлял, так что может дело, всё-таки, в роутере.

В общем, мытарства ещё не закончились. Можно попробовать обновить прошивку роутера или же купить уже новый. В принципе, наличие роутера для беспроводной связи контроллера и компьютера не обязательно, но я хочу в дальнейшем использовать роутер для создания локальной сети.
А вообще, время я получаю из сети, а старый компьютер к сети не подключен. Сначала надо было переделать схему, подключив плату RTC, и переписать скетч, чтобы иметь время своё, а потом уже добиваться прошивки и отображения диаграммы на старом компьютере без подключения интернета. Наверное так и поступлю.

 

Поменял контроллер NodeMCU на Wemos D1 Mini v4.0.0. Как видно на фото, он в 2 раза меньше, в остальном праткически не отличается. Разве что разъём у него не обычный USB, а Type-С, поэтому мне пришлось заказывать кабель Type-C/Type-A.



Дисплей тоже выкинул - он не нужен, поскольку данные буду смотреть на компьютере или смартфоне. Схемка стала намного меньше. Эта схема и так мала, но в ней в единственной будет платка RTC (с батарейкой), другие устройства будут получать от неё время по Wi-Fi.
Эта платка долго валялась на полке, батарейку не вытаскивал - подсоединил - время показывает, за несколько лет отстало на 2 мин.



Ещё заменил клавиатуру, у прежней стёрлись английские буквы, да на старом компе заменил мышку на новую.
Заказывал ещё самый простой и дешевый роутер, поскольку со старым ничего не добился.
В общем, теперь с аппаратным временем, т. е. полностью независим от интернета.
Диаграмму показывает, единственно, что ещё не согласовал программу рисования диаграммы с платой RTC, поэтому на диаграмме время пока не отражается. Как сделаю, вернусь к вопросу работы на старом компьютере.
Жаль, принтер тоже несколько лет не включался, чернила в печатающей головке засохли, нужно будет попробовать реанимировать, чтобы можно было нарисовать печатную плату. Если не получится, буду искать другие варианты.

 

Ну вот, всё работает и на новом, и на старом компьютере. Замена роутера помогла, теперь диаграмма рисуется и на старом компьютере через Wi-Fi, провода для прошивки новых версий программы не нужны. Я уносил платку на кухню и смотрел через 2 стенки на диаграмму на экране - связь хорошая, сбоев нет - новые точки (значения температуры и влажности) появляются каждую минуту. Точно так же должно будет работать и в теплице, а компьютер и роутер будут стоять в вагончике.
В принципе, можно открывать новую тему - о практическом регулировании климата в теплице, единственно, что нужно спаять вместе контроллер, датчик и модуль RTC на платке, но принтер не работает, чтобы нарисовать плату.
Впрочем, есть вариант, хотя и топорный - купить специальную макетную платку, но работать должно.

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

Итак, скоро проверка в деле, на даче.

 

Если данные не считать, то на основе чего будет строиться диаграмма?

 

Есть разница опросом датчика и накоплением данных внутри контроллера и считыванием их для своих нужд. Когда я считываю данные в браузер по Wi-Fi, контроллер работает в режиме передачи и расходует при этом максимум энергии. При опросе датчиков режим передачи не включается, поэтому токи намного меньше. На период отладки опрос датчиков у меня происходил с частотой 10 сек, сейчас - 1 мин, но вообще, наверное, будет 5 мин, поскольку все процессы в теплице довольно инерционны. В цикле - 288 опросов, что в итоге даёт 24 часа, после чего новые данные затирают старые.
И всё это накапливается внутри контроллера. Чтобы создать архив, требуется только автоматически передавать полностью заполненный массив данных 1 раз в сутки, а затем делайте с ним в браузере что хотите - контроллер при этом может продолжать спокойно спать.
Кроме того, есть модели ESP, потребляющие минимум энергии в режиме сна - микроамперы, кажется, ESP32 - С3. Подберу позже для того, чтобы все контроллеры могли работать от миниатюрных батареек.

 

Батарейное / аккумуляторное питание это конечно тема хорошая, у меня пока все бесперебойное питание устройств строится на 2х аккумуляторах 18650. За это время ни разу не подводило.
Давно хочу доделать схему универсального ИБП, но никак руки не доходят.
То что есть сейчас достаточно в принципе, заряд, питание от аккумуляторов при отсутствии сети. Но хочется статистики, количество циклов заряда разряда, график напряжения. Вобщем красоты добавить и аналитики.
А самое главное универсальности, чтобы данные с контроллера ИБП снимались например через I2C тогда не надо в каждой новой железяке городить огород с мониторингом.

Ну и актуальная на сегодня тема. Солнечные батареи. Есть китайский производитель http://www.consonance-elec.com/en/
Есть у них целое семейство контролеров зярядки от солнечных батарей - http://www.consonance-elec.com/en/?products_32/
Но вот индикация заряда, разряда и ошибки у этих контроллеров просто логическими уровнями индицируется, для визуального контроля хорошо, для автоматизации не очень удобно.

Прикупил так же попробовать такой модуль https://aliexpress.ru/item/1005009535888814.html
Но руки пока не дошли. Модуль сделан на IP5389, но отображения процессов в нем тоже или на несколько светодиодов или на семи сегментные индикаторы, никаких I2C, UART или подобных.
Но широкий диапазон напряжений, и количества и типов аккумуляторов.

Сейчас началась дача, не до экспериментов. Отложил ИБП до осени.

Опять же если прикроют мобильный интернет, то надо осваивать meshcore/meshtastic для организации связи дача <-> дом <-> смартфон. А там как раз нужны хорошие ИБП.

 

Ну это бесперебойное питание, но не автономное. Понятно, что при удалённом контроле Wi-Fi будет постоянно строчить, а любая ESP чрезвычайно прожорлива в этом режиме. Поэтому автономное питание отменяется - не хватит и АКБ.
У меня все устройства будут предельно простые - каждый должен состоять из одного контроллера типа Wemos D1 mini или ESP-01S. К одним будут цепляться датчики, другие будут стоять каждый рядом со своим регулирующим механизмом и включать его. Датчики тратят энергии очень мало, а к исполнительным механизмом всё-равно нужно подключать силовое напряжение, так что они будут питаться от адаптеров сети. Т. е. всё будет распределено в пространстве.
Wi-Fi, как писал уже, в автомате достаточно включать раз в сутки для сброса накопленной информации.
Да, когда я на даче, то буду производить много экспериментов, в ходе которых нужно будет не только считывать данные, но и изменять прошивку, но не на всех устройствах, а, в основном, только на контроллере, управляющем испытываемым механизмом регулирования. Впрочем, поскольку устройства, фактически, одинаковые и беспроводные, ничего не мешает прошивать запасное устройство по кабелю USB, а затем просто поменять их местами и всё.

 

Почему я думаю, что сделать батарейное питание мне удастся

Wi-Fi - хороший протокол, но он расчитан на быструю передачу больших объёмов информации, поэтому имеет рекордное токопотребление среди ближних систем связи. Поэтому сделать интерактивную систему управления практически невозможно потому, что в этом случае придётся передавать информацию пользователю непрерывно с небольшими интервалами времени, иначе он будет видеть не текущее состояние объекта, а прошлое. Но Wi-Fi - настоящий пожиратель энергии, поэтому, чем чаще соединение, тем быстрее происходит разряд батареи.
Однако я считаю, что постоянное наблюдение и попытки ручного управления удалённым объектом - это кретинизм. Управлять нужно непрерывно, и день и ночь, вручную это делать невозможно и такой подход исповедуют только гики, что-то понимающие в программировании, но ничего не понимающие в автоматизации. Система должна работать сама, т. е. автономно, а в этом режиме ей Wi-Fi не нужен, даже если она децентрализованная, т. е. состоит не из одного центрального контроллера и проводов, опутывающих всю теплицу, а собрана из нескольких отдельных контроллеров. Отдельные контроллеры удобнее - на каждый ИМ свой контроллер, никаких проводов. Спрашивается, а как, в таком случае они будут взаимодействовать? - Мне кажется, им это не очень то и надо, если в каждом контроллере прошита одна и та же управляющая программа, то каждый контроллер в высшей степени самостоятелен. Конечно, ИМ должны включаться и работать согласованно, но для этого частые и длинные сеансы связи не нужны.
То же самое с временем. Можно сделать одно устройство с RTC и синхронизировать время на всех контроллерах по нему раз в сутки.
То же самое и с накопленными данными - их можно тоже передавать пакетами в компьютер раз в сутки.

Таким образом, Wi-Fi будет включаться очень редко и потребление упадёт раз в сто, что позволит сделать всю систему на батарейках.

Да, но как же быть с прошивкой и оптимизацией режимов исполнительных механизмов и всей программы, требующих частых включений Wi-Fi? - Это временные мероприятия, на этот период налаживаемый контроллер можно и к сети подключать через времянку.
Так же и с контроллерами, управляющими исполнительными механизмами - поскольку сетевое напряжение к ним подводится всё равно, то для них вопрос автономного питания не стоит.