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

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

Это верно только отчасти. Есть задача - автономная теплица. АКБ без солнечной панели, GSM, зарядка раз в 1-2 недели. Здесь было бы полезно уметь засыпать и просыпаться раз в несколько минут.

 

Ок, скажу по другому - передо мной пока такой задачи не стоит

 

Давайте порассуждаем - вдруг я пропустил что-то важное в архитектуре Итак: у нас есть ядро, которое:

1. Умеет собирать данные с датчиков, пришпиленных к железке (Mega 2560 или Due);
2. Умеет обрабатывать RS-485 на уровне ядра - т. е. предоставляет минимально необходимый функционал для написания конкретной логики;
3. Умеет обрабатывать LoRa на уровне ядра - т. е. предоставляет минимально необходимый функционал для написания конкретной логики;
4. Пока не умеет, но будет - работать с ESP через AT-прошивку;
5. Будет уметь - работать с MQTT через ESP, т. е.: публиковать топики, подписываться на топики и т. п.;
6. Умеет добавлять данные любого типа в систему - тот случай, когда по приходу пакета с LoRa, например - надо добавить в систему новый датчик температуры.

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

а) указать, что Nextion используется на таком-то Serial (с этим проблем нет);
б) как-то описать, что и при каких условиях мы должны показывать на экране (устанавливать значение какой-то переменной на Nextion и т. п.)?
в) как-то описать - на какие входящие команды от Nextion мы реагируем (тут событийный интерфейс, тоже более-менее понятно).

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

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

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

 

Ввёл в ядро понятие "идентификатор кластера": переменная, содержащая адрес кластера, в котором находится устройство. Т. е. у нас есть: 256 кластеров, по 256 устройств в каждом. Каждое дочернее устройство сбора информации (и не только сбора) при своей настройке сможет быть привязано к определённому кластеру, помимо указания уникального адреса в кластере.

Соответственно, любой пакет, гоняющийся по транспортам, например, по RS-485 или LoRa - теперь так и просит в заголовке два байта: ID устройства и ID кластера, при помощи которых мы всегда сможем идентифицировать - какое устройство какого кластера пульнуло данные в эфир. Соответственно, в рамках одной сети при таком раскладе можно будет иметь N главных контроллеров, к каждому из которых будет привязано M устройств с теми же датчиками.

Надо браться за ESP, всё манкирую - там вагон нюансов...

З. Ы. Да, NodeMCU запустил, прошил тестовой прошивкой - работает, вещь норм, можно будет писать прошивку и под ESP, чтобы иметь возможность легко встраивать новые устройства в систему. Но это пока - на будущее.

 

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

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

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

 

Итак, что имеем на текущий момент по поддерживаемым командам через Serial:

1. GET=DATETIME, SET=DATETIME - получить/установить дату/время;
2. GET=SENSORS - получить информацию о поддерживаемых датчиках;
3. GET=TRANSPORT - получить информацию о поддерживаемых транспортах;
4. GET=FREERAM - получить информацию о свободной памяти;
5. GET=CPU - получить информацию о МК;
6. GET=CONFIG - получить конфиг;
7. GET=STORAGE - получить показания со всех датчиков хранилища.

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

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

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

 

Вот так выглядит первая версия конфигуратора (я предупреждал, что будет страшно ):



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

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

 

Попробовал отображать данные с датчиков, прописанных в конфиге, в софте:



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

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

Короче, как в старом ч/б-фильме: It's alive! It's alive!

З. Ы. Желающие пощупать - могут выкачать архив с гита: https://github.com/Porokhnya/ArduinoCore, расчехлить Мегу, закачать в неё прошивку, подключить пару датчиков (там в конфиге всё в комментариях понятно, что куда), запустить софт - и проверить, как оно.

 

Конфигуратор работает. Пытаюсь протестировать LoRa. Не получается. Загружаю тестовые программы LoRa на прием (SAM3X8E) и передачу (SAMD21E18A). Передаю строку"GET=DATETIME".
Модули видят друг друга, передают принимают. Может в Arduino Core нужен тестовый скетч?

 

Если данные ходят по LoRa - то значит, всё работает. Я где-то говорил, что команды автоматически через любой транспорт подхватываются? Это транспорт, что через него будет передаваться - дело КОНКРЕТНОЙ логики. Не надо, плз, считать ядро чем-то настолько универсальным, чтобы оно умело ещё и читать мысли Данные передаются/принимаются по LoRa? Если да - значит, ядро работает, как и планировалось. Что в конкретном проекте будет передаваться по этому транспорту - дело автора конкретного проекта

Или я неправильно понял, и в рамках ядра LoRa не работает? Обращаю внимание, что юзается вот такая библиотека: https://github.com/sandeepmistry/arduino-LoRa - там перечислены поддерживаемые чипы. Ядро по умолчанию работает на приём информации по LoRa, достаточно на передатчике выставить такие же настройки, как и на приёмнике (частота и пр.) - и отослать что-то в эфир, а в функции ON_LORA_RECEIVE в ядре вывести полученные данные в Serial, чтобы увидеть, работает или нет. Для ядра настройки LoRa указываются в конфиге.

 

Я второй день пытаюсь запустить модуль лоры на оранже, ни в какую не желает, это писец какой-то.

 

Загрузил "Ядро", поигрался с ним, Вроде всё работает ОК, но пока не разобрался, что- к чему. Буду изучать!

 

Обновил немного: добавил автоматический разбор пакета, приходящего от LoRa: теперь, если приходит известный пакет с показаниями с датчика - он автоматически добавляется в хранилище, событие при этом - не вызывается. Событие прихода данных по LoRa вызывается только тогда, когда принято что-то неизвестное, в общем.

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

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

З. Ы. Проверил - пакет разбирается правильно, в систему добавляется. Т. е. через LoRa теперь мона добавлять любые данные в хранилище, ляпота.

 

Добавил для транспорта RS-485 режим работы: мастер или слейв. В режиме слейв - транспорт слушает поток, разбирает пакеты по известным заголовкам и вызывает событие, мол, пришёл такой-то пакет, будь добр обработать, если хочешь.

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

Написал тестовый скетч для клиентского модуля на шине RS-485 - он отдаёт показания с двух якобы датчиков.

Проверить прямо через RS-495 - пока не могу, проверял через терминальную программу, посылая модулю пакеты (модуль имеет номер 3 на шине, и входит в один кластер с контроллером):

В терминалке видно, что модуль отвечает, следовательно, должно работать (но не обязано, конечно). Посему к интересующимся просьба: если есть такая возможность - проверить, как оно работает по RS-485. Для этого надо:

1. Взять МК номер 1 (например, Arduino UNO);
2. Закачать в него скетч из папки TEST;
3. Закачать ядро в МК номер 2;
4. Соединить UART двух модулей через RS-485: Serial модуля из пункта 1 с Serial2 контроллера, на который закачано ядро;
6. Не забыть правильно подключить пины DE для RS-485 (настройки в прошивках);
5. Подключить питание, открыть монитор порта, и смотреть - при запросе модуля номер 3 на шине - в мониторе порта должно появиться что-то типа "RS485: Userdata sensor added!". При этом, если конфигуратор запущен - там можно будет увидеть два новых датчика с именами Remote1 и Remote2.

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

 

Проверил: всё гоняется по RS-485, пруф:



Последние две записи - это данные с Arduino Uno, прошитого тестовой прошивкой (которая потом ляжет в основу прошивки для модулей на шине RS-485). Сейчас контроллер опрашивает 256 клиентов на шине, для каждого из них, если клиент отзывается - запрашивает показания датчиков. Ограничений на кол-во датчиков в клиенте уже нет, главное, чтобы имена всех датчиков были уникальны в пределах кластера - это будет настраиваться простеньким визуальным конфигуратором для модуля с датчиками

Соединил UART двух модулей перекрёстно, для пробы. Погонял и под RS-485, на отладочной плате - работает и так, и так. Будем считать, что теперь показания датчиков можно собирать и по RS-485, значицца.

Конечно, ещё много чего к оптимизации - например, некошерно постоянно опрашивать модули, которые не отзывались на шине RS-485 несколько раз, ибо - адресов дофига, пока весь круг пробежишь, набегает солидно времени. Сейчас у меня минимальный промежуток между опросами двух соседних адресов - 200 мс, т. е. максимум 5 адресов в секунду, следовательно, полный цикл - это 256/5 = 51 секунда, не сильно-то и быро Но это уже будем допиливать по мере востребованности, считаю.

Наверное, всё-таки сокращу кол-во устройств на шине RS-485, ибо пока нефик