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

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

Очень жаль... У меня АТ прошивка тоже работает, но иногда с ней возникают необъяснимые глюки. Вот заметил такую особенность - чем больше данных гоняется через ЕСП - тем реже он зависает. Например: когда подцеплена ВЕБ- морда - зависаний вообще нет, а если просто отправка данных на gardenboss и thingspeak то зависает, причём не предсказуемо, может проработать несколько суток, а может и несколько минут.

 

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

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

Ну и вот - теперь можно обеспечить такую кучу всего в одном месте. Всё, что я вижу далее - это поддержка работы через ESP, поддержка работы с MQTT - и, собственно, баста для первой версии. Далее - надо будет думать над конструктором логики поведения прошивки. С остальным - уже без разницы, на чём и под чем будут работать датчики: хочешь NodeMCU (кстати, заимел пару таких плат, но MicroUSB-шнурок, валяющийся в загашнике, оказался только для зарядки, так что пока закачать в плату ничего не могу), хочешь - голое ESP со своей обвязкой, хочешь - чего-то на RS-485 шине, не вопрос: все данные будут собраны в одно хранилище (не забываем, что головной контроллер будет настраиваться через софт, и там все подписки и пр. можно будет легко прописать).

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

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

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

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

 

Нашёл в соседней теме https://www.forumhouse.ru/threads/402989/ некоторую информацию по стандартам программируемых контроллеров, изучаю, отдельное спасибо @Greeds74 за предоставленные описания, от которых можно оттолкнуться и поразмыслить - каким путём идти: изобретать велосипеды или...

 

День добрый, коллеги! Собственно, в той ветке совсем не полное описание...Но это не важно - у меня есть предложение к сообществу. Давайте сделаем наши системы совместимыми - для начала на уровне хотя бы протокола обмена. Мне, например, возиться с MQTT - зачем, когда у вас уже есть готовое решение. Так же я могу для вас подготовить небольшой модуль, который будет логику выполнять. Взаимная выгода - тем более опыт объединим.

 

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

 

Для будущего проекта вполне можно предложить вот такой вариант - обмен по SPI например на 18МГц. Но вот только надо с ресурсами определиться. Я для начала думал про modbus - но он не обеспечит нужной пропускной способности.
Если надумаете - то вместе можем создать весьма привлекательный продукт. Причём недорогой, массовый и универсальный.

 

я что-то упустил - в этом проекте уже есть поддержка датчиков с nRF? А есть ли возможность сделать вывод данных из централизованного хранилища на Nextion 2.4 TFT 320 x 240?

 

Некоторые размышления по поводу применения MODBUS в наших устройствах.
Протокол неплохой и скорость обмена достаточная для наших устройств.
MODBUS в основном предназначен для применения в промышленных системах для унификации связи контроллеров различных производителей. Он позволяет непосредственно оперировать регистрами микроконтроллера, ну и конечно осуществляет контроль целостности передаваемых данных.
В принципе у Димы уже реализована аналогичная система, только команды звучат немного по другому.
А для оперирования произвольными данными создан пользовательский датчик, с помощью которого можно передавать/принимать различные данные (как я понял). В крайнем случае можно организовать псевдоMODBUS в строке обмена к примеру канала RS485 (и других каналов).
Не знаю, есть ли контроль передаваемых данных (контрольная сумма), и повторение обмена при ошибке передачи.
В контроллере теплицы применять его не имеет смысла. все датчики уже прописаны, логика работы определена.
В ArduinoCore о применении MODBUS нужно подумать нужен ли, чем будет управлять и как встроить в существующую систему. Это вопросы больше к Диме так, как он лучше ориентируется в своей системе. Это вопросы будущего, пока не до конца определены все задачи и не понятно кого заинтересовала Arduino Core. С моей стороны у меня уже есть намерение применить в двух проектах (с разрешения Димы и соответствующих отчислений).

 

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

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

 

Собрал всю информацию с постов по Arduino Core в отдельный файл, что бы не потерялось и удобнее пользоваться (как инструкция по применению). Рекомендую всем кто планирует применять Arduino Core поступить так же.

 

заказал LoRa, буду признателен за "прописку" Nextion 2.4 TFT

 

Ок, после того, как припилится ESP и MQTT.

 

Для LoRa (как и nRF) актуально, чтобы был предусмотрен режим "сна" микроконтроллера. Иначе не реализовать преимущество батарейного питания и беспроводной связи.

 

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

 

Ессно. Но это актуально только для модуля с датчиками, а не для центрального контроллера. Ядро - под центральный контроллер