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

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

Для нового проекта - создал репозиторий на гитхабе, вот он: https://github.com/Porokhnya/smartHomeSystem

Собственно, там будет лежать то, над чем я работаю в текущий момент времени. Сейчас там, например, лежат исходники и тестовый скетч, который компилируется под Mega2560 (скомпилируется и под Uno, если поменять Serial1 для RS-485 на Serial). Скетч пока работает как модуль, для компиляции как контроллер - оставлены заглушки на будущее.

Исходники собственно ядра - лежат в подпапке src. Кому интересно пока абстрактно скомпилировать с разными настройками - качайте, и разархивируйте, чтобы всё добро лежало в папке "smartHomeSystem", т. е. внутри этой папки должен лежать файл "smartHomeSystem.ino" и подпапка src со всеми исходниками.

Кой-какие настройки ядра - в папке src/config.h, но там ещё мало чего есть. Можно пошерстить исходники на предмет "посмотреть, шо и как там устроено". В принципе - там пока всё просто и прозрачно, надеюсь.

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

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

С Сергеем @HANTER333 сейчас будем пытаться сделать проект для протеуса, чтобы пока не собирать всю чепуху в железе. Когда (и если) получится - тоже будет на гитхабе.

Компилируемость на Due - пока не проверял, не время. Но для контроллера, пмсм - как раз лучше использовать что-нибудь типа Due или STM32 - чтобы оперативки побольше Пока - Mega потянет, да и Uno - тоже.

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

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

 

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

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

Есть такое слово в программистском сленге - фреймворк. Грубо говоря - это ящик с инструментами, откуда всегда можно взять нужный, сделать с его помощью работу, положить на место.

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

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

И смысл его прост донельзя: есть центральная железка, к которой подключено совсем немного: RS-485, ESP, LoRa, кнопочка и светодиод. Эта железка прошита прошивкой контроллера.

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

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

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

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

Лирика закончена

 

Начал потихоньку пилить контроллер - добавил поддержку прослушки на предмет входящих команд, решил оставить старый формат:

Код:

=> GET=ID
<= OK=ID|1234

Добавил пока поддержку парочки тестовых команд, и чуть расширил возможность прослушки: сделал, чтобы можно было слушать команды с неограниченного числа источников:

Код:

StreamListener controllerCommands(Serial); // обработчик команд из Serial

StreamListener controllerCommands2(Serial1); // обработчик команд из Serial1

// говорим контроллеру, чтобы он слушал команды из Serial
  controller.addStreamListener(controllerCommands);

// говорим контроллеру, чтобы он слушал команды из Serial1
  controller.addStreamListener(controllerCommands1);

Т. е. налицо нормальный программный интерфейс: кому захочется, чтобы контроллер обрабатывал команды из чёрта лысого - пишет наследник класса Stream (там несколько методов надо реализовать, класс Stream входит в состав Wiring, его заголовочный файл валяется тут: hardware\arduino\avr\cores\arduino\Stream.h. Надо всего-лишь определить вот такие методы - и всё:

Код:

  public:
    virtual int available() = 0;
    virtual int read() = 0;
    virtual int peek() = 0;
    virtual size_t write(uint8_t) = 0;

Такой же механизм я применял в контроллере теплицы. Ладно, с этим вроде ясно, далее...

Сначала я хотел, чтобы контроллер сам сообщал в Serial, что он делает. Потом понял, что это - подход не очень, потому что в данный конкретный момент времени состояние контроллера - недетерминировано: он может находиться, например, в режиме поиска модулей при старте, или ещё чего. Да и тот поток (Serial), куда планировалось выводить "бормотание" контроллера - не панацея: например, при коннекте с андроид-приложения по Wi-Fi - будет другой поток общения - тот Serial*, куда притаранена ESP. Именно поэтому решил и тут не отходить от системы "запрос-ответ" - она себя уже не раз показала с хорошей стороны.

Далее на очереди - очень хорошо продумать механизм работы контроллера - и потихоньку написать первую версию с минимальным набором функционала, для начала. Дело это не очень простое, чтобы вы понимали: транспортов может быть несколько (RS-485, LoRa, Wi-Fi) - каждый надо просканировать на предмет поиска зарегистрированных модулей, потом опросить каждый модуль, вытянув из него все потроха, сохранить всё это дело к себе, периодически опрашивать, пинговать, удалять из списка активных по таймауту и т. д. и т. п.

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

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

Такие дела.

 

А почему Proteus? Не факт что Proteus отработает нормально. У тебя же есть отладочная плата STM32 и программатор ST-Link.
Сейчас выпустили отличную поддержку STM32 для Ардуино с большим набором плат.
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Кроме этого, возможно не стоит загружать вариант поддержки STM32 https://github.com/rogerclarkmelbourne/Arduino_STM32
На некоторых платах она глючит, не прошивает контроллер 407.
Может быть лучше загрузить https://github.com/victorpv/Arduino_STM32.
Вариант нужно проверять на Ваших ПК. У меня на двух ПК прошивает нормально, а на остальных двух отказывается категорически. Переустановка, очистка, танцы с бубном не помогают.
Новая поддержка STM32 эту проблему сняла. Кроме этого можно настроить прошивку так, что после записи программы начинает работать USB как КОМ порт и в него можно выводить отладочную информацию.

 

Да чтобы в железе пока не собирать, всего лишь.

Иду последовательно: сначала проверяю компилируемость под Uno/Mega, потом буду - адаптировать под Due, потом уже - STM32. Довод - простой: если контроллеру нужен 32х-битный МК (Due или STM32), то для модулей чаще всего достаточно восьмибиток. Да и в каких-то прикладных задачах для контроллера может быть вполне достаточно Меги - если кол-во данных в системе небольшое, то всё может легко влезть и туда.

STM32 - обязательно будет, как только я напишу и проверю основной костяк кода. Сейчас продумываю реализацию контроллера.

З. Ы. На гитхабе в папке examples выложил пару примеров - там видно, сколько занимает подключение ядра - совсем немного. А остальное - логика конкретного проекта. Реализую контроллер, оттестирую на протеусе (если потянет) и на железе (две Mega2560), ну а потом - уже можно будет использовать ядро для реализации конкретного проекта, постепенно дорабатывая всякие плюшки - как я говорил, на первом этапе будет только RS-485, остальные транспорты - подтянем потихоньку.

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

 

Спасибо, Дмитрий, очень хорошая задумка. Мне что-то подобное приходило в голову, в смысле сама концепция, но я такое не осилю. Буду рад попробовать ваш проект в деле. Сейчас есть некий зоопарк нагрузок, работают на ESP+реле+MQTT, хочу перевести все на провод, ему доверяю больше) Пробовал построить на 1-Wire, но с эмуляцией slave постоянно какие нибудь глюки. С чипами типа DS2408 как slave и ардуино в качестве master работает нормально, но сами чипы дороговаты.
Буду ждать продолжения!
PS. Я в программировании ни "бум-бум", ардуину только не так давно начал осваивать, так как очень интересно это направление, вроде немного получается.

 

Дмитрий здравствуйте, согласно логике проекта контроллер и модуль разные устройства, соединенные через какой то транспорт, вопрос можно ли запустить контроллер и модуль на одном устройстве?

 

А Какой в этом смысл, я не понимаю? Смысл данного проекта быстро собрать под свои нужды 2+ модуля и коммуницировать между ними по удобному интерфейсу, добавляя и убирая их при необходимости. Если вам для отладки, смоделируйте в Proteus'e, соединив по UART.

 

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

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

 

Сделал пробную разводку контроллера датчиков и контроллера фрамуги для RS485 под корпус G201CMF.
Контроллер датчиков:

 

Контроллер фрамуги:
Реле с рабочим током 6А.
Имеющийся линейный привод на 12В имеет сопротивление 3 Ом, значит пусковой ток не превысит 4А.
Обратная связь от концевиков не предусмотрена. Концевики должны быть встроены в привод.
На плате предусмотрено место под магнитный или гравитационный датчик положения. Поэтому сам корпус можно поставить на форточку вблизи от линейного привода.
Недостатки такого решения - более дорогие реле.

 

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

 

Наверно. я не совсем понял, в контроллере предусмотрено хранилище данных, или он только будет передавать их от модуля к модулю?

 

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

 

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