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

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

Это и есть своего рода аккумулятор.

 

Может тогда такие часы и плюс 32 кило EEPROM "пиши не хочу"
Сюда конечно нужен акум.

 

Вот интересное решение некоторых задач.
Ионистор как раз и стоит в первых часах.

 

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

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

 

как будет отслеживаться момент "когда нужно"? а если все модули одновременно решат это сделать?

и где же тут унификация универсальных модулей?

 

1. Каждый модуль можно настроить на свой интервал. Если все модули начнут одновременно - в nRF есть механизм разрешения коллизий.

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

 

принял сигнал от контроллера - прожевал - если надо: 1) опросил датчики - выплюнул данные и/или 2) выполнил включение

- да кто ж откажется то!

 

Ну вот смотрите: по сути, смешивать исполнительный модуль с модулями с датчиками - как-то не того, мне кажется. У нас сейчас какая архитектура универсальных модулей с датчиками: каждый такой модуль может иметь на борту до трёх датчиков разных типов, и умеет работать как по шине 1-Wire (проводное соединение), так и по радио (беспроводной режим). Эти модули предназначены только для получения информации с датчиков, всё.

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

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

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

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

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

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

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

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

 

Как вижу проблему исполнительных модулей я:

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

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

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

Небольшой пример: допустим, правило у нас сработало, и в настройках правила сказано, что при его срабатывании надо выставить на пине номер 40 высокий уровень. В этом случае мега пошлёт в эфир команду "запрошено выставление высокого уровня на пине номер 40". Но и тут много тонких мест, как понимаете: в приведённом примере совершенно недопустимо выставлять на пине номер 40 высокий уровень, т. к. команда должна пойти в эфир, и только. Т. е. думать есть много над чем.

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

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

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

 

Вообще подумалось, что стоит рассматривать исполнительный модуль как пин (или набор пинов). Тогда очень многое упрощается, в принципе. Буду обдумывать

 

Отвлекаясь от исполнительных модулей: назрела острая необходимость уменьшать память, занимаемую правилами в оперативке.

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

Что скажете? Мне кажется, что 20 правил при том, что они, как правило (сорри за тавтологию) парные - это ни о чём. А типичная команда на отсыл другому модулю, при срабатывании правила - съедает 20 байт в оперативке, т. е. на 20 правил - полкило, это ни в какие ворота!

 

"микросхема nRF24L01, сконфигурированная в режиме приёма (RX), может получать пакеты данных от шести разных передатчиков, работающих на одном частотном канале"..."Применение однокристального приёмопередатчика nRF24L01 целесообразно в тех случаях, когда необходимо передавать данные в режиме «точка–точка» или создать простую беспроводную сеть типа
«звезда»" - если я ЭТО правильно понял, то одна nRFка должна быть сконфигурирована в режиме приемника и может принимать данные только от 6 nRF передатчиков? В связи с этим возникает более глобальный вопрос:
1) не следует ли поменять nRF на 433 МГц?
2) в противном случае для юзания исполнительных (или только одного исполнительного?) модулей потребуется конфигурация еще 1+6 (или 1+1?) дополнительных nRFок?

 

Если честно, я пока об этом не думал, но читал статейки, как делают топологию сети на nRF. Вот придёт @Snark - и всё расскажет

 

Может Это поможет
Сеть беспроводных датчиков с nRF24L01

 

Дмитрий!
Последний вариант прошивки и конфигуратора с уменьшенным дискретом времени работает.
Достаточно просто все корректируется.
В режиме полива время осталось в старом варианте, как я понял?
Есть у меня вопросы по GSM, т. к работает через раз.
Команды отдельные исполняет, на звонки смс приходят по его собственному усмотрению.
В мониторе порта снял кучу логов. Если в личку постучусь за помощью, что бы здесь не захламлять, что скажете?