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

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

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

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

 

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

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

 

Реализовал первую версию выгрузки конфига в контроллер из конфигуратора:



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

Код:

void setup()
{
  Serial.begin(CORE_COMMUNICATION_SPEED);
  // все необработанные данные из Serial будут перенаправлены в функцию unhandledCommandHandler
  Core.setup(unhandledCommandHandler);
  // пробуем загрузить конфиг из EEPROM, если не получится - грузим из флеша конфиг по умолчанию
  if(!Core.loadConfig())
  {
     Core.saveConfig(defaultConfig,sizeof(defaultConfig),true);
     Core.loadConfig();
  }

  // говорим ядру, чтобы начинало работу
  Core.begin();


}
//--------------------------------------------------------------------------------------------------------------------------------------
void loop()
{
  // обновляем показания с датчиков
  Core.update();
  // обрабатываем входящие по Serial команды
  Core.handleCommands();


}
//--------------------------------------------------------------------------------------------------------------------------------------

Т. е. совсем немного по объёму, и не пугает сильно Также сделал выключение логики ядра для LoRa - настройка CORE_LORA_DISABLE_CORE_LOGIC в CoreConfig. h - если её раскомментировать, то ядро не будет работать с LoRa, и можно будет ручками, если надо - пихать в эфир любые данные, ну и принимать их, соответственно, по событию.

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

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

З. Ы. Иконку на сохранение конфига надо поменять - неполиткоректная

 

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

 

Обновил ядро, ввёл поддержку работы с SD.

Настройки в CoreConfig. h:

Код:

#define CORE_SD_SUPPORT_ENABLED // закомментировать, если не нужна поддержка SD
#define CORE_SD_USE_SDFAT // закомментировать, если не надо использьвать SdFat (вместо SdFat будет использоваться штатная библиотека SD)
#define CORE_SD_SDFAT_SPEED SPI_HALF_SPEED // скорость работы SD для библиотеки SdFat
#define CORE_SD_CS_PIN 4 // номер пина CS для SD-карты

Введены команды:

1. GET=LS|FolderName - получить список файлов директории, примеры:

GET=LS - получить листинг корневой папки, выхлоп у меня:

SMS <DIR>
STAT. SMS
LOGS <DIR>
MQTT. INI
MQTT <DIR>
DATA <DIR>
LCD <DIR>
hdr. htm
ftr. htm
[END]

GET=LS|MQTT - получить листинг с папки MQTT, выхлоп у меня:

MQTT. 0
MQTT. 1
[END]

GET=LS|LCD|TEMP - получить листинг с папки LCD/TEMP на SD

2. GET=FILE|FilePath - получить содержимое файла, примеры:

GET=FILE|MQTT.INI - содержимое файла MQTT. INI в корне диска
GET=FILE|LCD|TEMP|0.inf - содержимое файла LCD\TEMP\0.inf

Любая выдача данных с SD заканчивается последовательностью "[END]\r\n", чтобы можно было в программе понять, где конец данных.

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

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

Так что пошёл думать, как это добро в конфигуратор ядра припилить

 

Дима, есть пожелание изменить работу тачскрина. Звуковой сигнал звучит после отпускания кнопки. А так как не всегда четко отрабатывает тачскин (проверю еще с другис дисплеем). не понятно кнопка сработала или нет. На втором дисплее работает лучше, но сигнал лучше бы изменить.

 

Сильное желание? Вот прям настолько сильное, что с этим жить нельзя? Я не при чём - я проверяю нажатие кнопки, которое мне выдаёт наружу библиотека UTFT_Buttons - как только засеку нажатие - СРАЗУ пищу. Видимо, она считает за нажатие факт нажатия и отпускания кнопки, лезть сейчас в кишки - нет ни желания, ни времени: помнится, от тебя была поставлена задача, и я не могу метаться, как уж на сковородке, надо понимать. Я не могу работать в условиях, когда постоянно дёргают и переключают туда-сюда

 

Обновил ядро, добавил возможность просматривать SD-карту и файлы на ней:



Слева - дерево, по двойному клику на файл - он вычитывается и показывается в ТЕКСТОВОМ виде справа. По ходу перепилил в конфигураторе логику работы с COM-портом, теперь должно работать повеселее.

Сразу говорю - делать полноценный проводник - не буду. В будущем, ВОЗМОЖНО, появится кнопка "Удалить выбранные файлы", но - не более того.

 

Ушёл смотреть, что там можно сделать с этим грёбаным писком.

 

Обновил прошивку контроллера теплицы - наконец-то сделал автовыбор платы (теперь не надо ручками переключать в Globals. h между Mega и Due), плюс - изменил поведение пищалки под Due - теперь она пищит в момент нажатия на кнопку, а не в момент отпускания. Пришлось лопатить библиотеку UTFT_Buttons, благо, она у меня рядом с прошивкой и уже частично перелопачена

@promavto - пробуем, не стесняемся

 

Не нервничай И поздравляю. Заработала.

Есть несоответствие отображения датчиков температуры. На дисплее TFT отображается температура "снаружи", а в конфигураторе этот же датчик отображается "Т внутри". Может поэтому нет управления фрамугами в автоматическом режиме? Прописал в правилах, регулирование заработало. Отлично работает!

 

Эээх, когда начнём читать настроечные файлы? Файл Configuration_DUE.h:

Код:

#define TFT_SENSORS {"STATE",StateTemperature,0,"Снаружи"}, {"STATE",StateTemperature,1,"Внутри 1"}, {"STATE",StateTemperature,2,"Внутри 2"}, {"HUMIDITY",StateHumidity,0,"Si7021"}, {"HUMIDITY",StateHumidity,1,"DHT22"}, {"LIGHT",StateLuminosity,0,"Освещённость"}

Правим индексы и надписи тут, и не паримся. На дисплее просто отображается температура с определённого датчика, к правилам она никаким боком.

Плюс в конфигураторе - можно ОТДЕЛЬНО каждому датчику имя задавать, и это имя никак не связано с тем, что показывается на TFT, очевидно. Короче, никакого криминала, всё настраивается.

 

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

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

 

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

1. В конфигураторе в дереве слева есть пункт меню "подпрограммы". Выделяем его, справо видим список подпрограмм и кнопки редактирования/удаления/добавления.

2. Каждая подпрограмма - это набор инструкций, хранящийся в EEPROM.

3. Выглядит подпрограмма в конфигураторе набором инструкций, типа:

• Получить значение с датчика (индекс датчика, т. к. имя тут хранить - избыточно)
• Сравнить со значением 31 - например, сравниваем температуры
• Если больше
• Высокий уровень на пин (номера пинов)
• Попереключать уровни на пине (пин, кол-во раз, частота) - т. е. моргаем светодиодом
• Поковырять в носу (кол-во ковыряний)
• Если меньше
• Низкий уровень на пин (номера пинов)
• Поспать 10 секунд
• Конец сравнения
• Тут ещё могут быть инструкции
• Конец подпрограммы

На внутреннем языке (байты заменены мнемоникой) подпрограмма может выглядеть так:

Код:

BEGIN
    IF SENSOR(0) > 31 AND SENSOR(1) > 30
        PIN_HIGH 7,8,9
        PIN_SWITCH 13,5,200
        PICK_NOSE 3
    ELSE IF SENSOR(0) < 30
        PIN_LOW 8
        DELAY 10
    ENDIF
END

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

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

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

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

Кто что скажет умное по поводу?

 

Дима привет!
Закончил проектирование "Базового" варианта контроллера теплицы. Размер платы соответствует размеру 7.0" дисплея. Все функции "Максимального" варианта сохранены. Заказал в Китае 10 плат (выгоднее 10 шт.). Комплектующие уже в пути.

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