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

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

@Berendey-70, железок много? деть некуда? тема не о чем. даже у лома забитого в предохранитель есть ограничение) Решать, в любом случае DIYMan, мне причина понравилась)

 

А вообще есть Activation by Personalization и Enable ACK

 

Ребята, об чём спор? Как я вижу работу LoRa: модуль, любой - он всегда молчит, может - даже спит и просыпается по прерыванию, как вариант. У контроллера есть уникальный номер (на примере Due - номер проца). При регистрации модуля - он сохраняет у себя номер контроллера, усё, в первом простейшем приближении (т.е. регистрация с настройками по умолчанию).

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

Идентификация в системе - ключи вида "ID контроллера - ID модуля". Если кто-то поймал пакет не от того контроллера - в /dev/null, и всё.

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

На примере модуля управления по SMS: как только соединение с оператором установлено - модуль посылает в эфир событие "Можно отсылать СМС" (вернее, контроллер забирает у модуля это событие и пушит его в общий эфир). Кому надо - поймают и поймут, что с этим делать. Также модуль периодически может слать событие "Уровень сигнала GSM", кому надо (например, модуль дисплея) - отобразит, и всё.

Главный пойнт в том, чтобы сделать хождение событий - только по факту их изменения, сделав их по-максимуму простыми, например: если изменилось значение уровня физического пина, то модуль может послать событие "Дискретный пин номер 445 изменил значение 1 на 0", ну и т. п. А кто и как будет на это реагировать - дело десятое.

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

[GPIO:456]0=>1

При этом реагировать на команды вида

[GPIO:ALL]
или
[GPIO:345]
и выводить текущий статус дискретного входа/выхода. Ну и подобные команды по датчикам и т. п., типа

[RESET]

(начать работу сначала, с поиска модулей и далее по списку).

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

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

И, да - эта система - логическое развитие текущей, только с разнесением функционала на разные дешёвые железки. Надо MQTT? Да пожалуйста - вот модуль, который умеет в это дело, и транслирует показания датчиков в брокер, настройки - сквозь главный контроллер на экране смартфона, например.

Тут самое сложное - это настройки, механизм должен быть универсален, насколько это возможно.

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

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

 

Хочется понять главное, какая основная цель нового проекта? Теплица или любой объект/комплекс объектов, для которых нужно управление контроллером?
Если одно из основных желаний и стимулов

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

 

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

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

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

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

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

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

 

Кстати, подобная описываемой система реализована в MySensors Там ограничение датчиков на систему - 255, сейчас порыл немного исходники - многое пересекается с моими мыслями.

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

 

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

 

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

 

Добрый день, закончил свой проект контроллера, функционал описывал ранее. Реализован полностью на готовых китайских железках. Архитектура совпадает с изложенной Дмитрием в последних постах. Вся система реализована на 4 МК. с разделенным функционалом и связью между собой "что у меня есть - то отправил, кому что надо тот это и возьмет".Насчет смартфонов, полностью согласен. пора уходить от всех видов дисплеев на контроллерах.

 

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

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

Код:

//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// подключаем ядро
#include "src/core.h"
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// хранилище, где мы будем хранить информацию
#include "src/storage/eeprom.h" // будем хранить во встроенной EEPROM
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// подключаем транспорты, которыми будем пользоваться
#include "src/transport/rs485.h" // подключаем транспорт RS-485
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// объявляем наши транспорты
RS485 myRS485(Serial, 4); // работаем с Serial, пин переключения приема-передачи - 4
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// наши виртуальные датчики в системе, которые мы транслируем в сеть
VirtualSensor temperature(Sensors::Temperature, 0); // датчик температуры с уникальным номером 0 в рамках системы. Всего номеров - 0-65534
VirtualSensor humidity(Sensors::Humidity, 1); // датчик влажности с уникальным номером 1 в рамках системы. Всего номеров - 0-65534
VirtualSensor pinState(Sensors::GPIOState,2); // состояние пина, в нашем случае - флаг аварии, что температура на удалённом модуле превысила 30 градусов. ID в рамках системы - 2

// теперь датчики, за изменениями значений которых мы следим в рамках системы
VirtualSensor remoteTemperatureSensor(Sensors::Temperature, 100, 10000); // следим за датчиком номер 100 в рамках системы, сбрасываем его показания, если в течение 10 секунд ничего не приходило из сети
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
void setup()
{     
  // поднимаем Serial
   Serial.begin(57600);

   // настраиваем пин 13 на выход, чисто для теста
   Pin::mode(13,OUTPUT);
   Pin::write(13,LOW);

  // инициализируем хранилище
  Storage.init(100); // храним служебные настройки, начиная с адреса 100

  // сообщаем модулю о хранилище, где он будет хранить его настройки
  Module.setStorage(Storage);

  // говорим модулю, какими транспортами пользуемся
  Module.addTransport(myRS485);

  // добавляем в систему датчики, которые мы транслируем в сеть
  Module.broadcast(temperature);
  Module.broadcast(humidity);
  Module.broadcast(pinState);

  // добавляем в систему датчики, за показаниями которых мы следим
  Module.observe(remoteTemperatureSensor);
 
  // начинаем работу модуля, имя модуля попадёт в контроллер при регистрации модуля в системе
  Module.begin("Имя модуля");
}
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
void loop()
{
  // для теста - раз в 5 секунд обновляем датчик температуры тупым значением. Его показания уйдут в сеть.
  // по факту - тут можно читать с DS18B20, например.
  static int16_t cntr = 0;
  static uint32_t lastMillis = 0;
  if(millis() - lastMillis >= 5000)
  {
    cntr++;
    if(cntr > 100)
      cntr = 0;

    Temperature t{cntr,0};
    temperature.setTemperature(t); // установили температуру, она уйдёт в сеть
   
    lastMillis = millis();
  }

  // наблюдаем за изменением датчиков, за которыми следим
  if(remoteTemperatureSensor.triggered())
  {
    // температура получена по сети (или сброшена по таймауту), что-то делаем с температурой по факту

    if(!remoteTemperatureSensor.hasData())
    {
       // нет данных с датчика, надо взводить аварию
       
       // зажигаем светодиод аварии
       Pin::write(13,HIGH);
       
       // и говорим в сеть, что у нас авария
       pinState.setGPIO(1);
    }
    else
    {
      //данные с датчика есть, проверяем на уставку в 30 градусов
      Temperature remoteTemperature = remoteTemperatureSensor.getTemperature();
      Temperature alert{30,0};

      if(remoteTemperature >= alert)
      {
        // авария !!!
       
        // зажигаем светодиод аварии
       Pin::write(13,HIGH);
       
       // и говорим в сеть, что у нас авария
       pinState.setGPIO(1);
      }
      else
      {
        // нормальное поведение, гасим светодиод аварии, и сообщаем в сеть, что всё норм
        Pin::write(13,LOW);
        pinState.setGPIO(0);
      }
     
     
    } // else has data

   
   
  }
 
  // обновляем модуль
  Module.update();
}
//-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Надеюсь, этот пример понятен. Буду рад, если отпишетесь, где тонкие места. Типов виртуальных датчиков - предусмотрел кучу:

Код:

enum class Sensors
{
    Temperature, // температура
    Humidity,    // влажность+температура
    Luminosity,    // освещённость
    SoilMoisture, // влажность почвы
    DateTime, // дата/время от контроллера
    GPIOState, // состояние пина (0,1)
    ADCValue, // значение АЦП
    BatteryPower, // заряд батареи
};

 

Дмитрий, если я правильно понял, Вы не планируете делать общее хранилище, каждый модуль следит за нужным ему виртуальным датчиком (командой)?

 

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

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

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

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

А скажите мне пж, как у вас реализован обмен - каждый модуль без спроса в эфир в любой момент времени вещает? А как с RS-485? Спрашиваю не зря - изобретать велосипеды - дело неблагодарное. Вот сейчас рою MySensors - наворочено там тоже до жопы уже, сходу не вникнуть...

Буду признателен за ответ

 

Мы писали, мы писали - наши пальчики устали Вот что накатал в виде текста, вроде как учёл практически всё. Буду признателен, если укажете на слабые места:

Код:

    структура пакета сообщения
   
    поскольку у нас существуют разные транспорты, мы должны корректно понимать, от какого модуля в рамках какой системы ходят данные.
    поэтому идентификация в рамках системы происходит посредством ID контроллера, а каждый модуль системы имеет свой уникальный внутренний
    номер. При регистрации модуля в контроллере модулю прописывается ID контроллера.
   
    каждое сообщение должно содержать ID контроллера, ID модуля, тип сообщения. Изменяемые данные - варьируются в зависимости от типа сообщения.
    события - являются частным случаем сообщений, и обрабатываются перед обработкой сообщений.
   
    размерность:
   
        ID контроллера - 4 байта
        ID модуля - 1 байт (максимум 254 модуля в системе, адрес 0xFF - широковещательный)
        Тип сообщения - 2 байта
   
    -------------------------------------------------------------------------------------------------------------------------------------------
    типы сообщений с примерной структурой пакетов (байты перечислены по порядку, начиная с нулевого).
    -------------------------------------------------------------------------------------------------------------------------------------------
   
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "сканирую эфир"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        посылается при начале работы контроллером, предназначено для поиска зарегистрированных модулей.
        Модуль при этом должен сброситься на начало работы своей логики (под вопросом).
       
        структура:
       
            ID контроллера
            ID модуля, к которому направлен запрос
            Тип сообщения - "сканирую эфир"
   
   
        как только модуль принял сообщение, и оно адресовано ему - он отсылает через транспорт, которым получено сообщение, ответ вида "я на связи"
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "я на связи"
    -------------------------------------------------------------------------------------------------------------------------------------------

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

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "пинг"
    -------------------------------------------------------------------------------------------------------------------------------------------

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

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "понг"
    -------------------------------------------------------------------------------------------------------------------------------------------
       
        отсылается модулем на контроллер как ответ на сообщение "пинг", структура:

        ID контроллера
        ID модуля
        Тип сообщения - "понг"
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "регистрация исходящего слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером в эфир как запрос на регистрацию исходящего слота модуля в контроллере, структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "регистрация исходящего слота"
            нагрузка:
                - номер исходящего слота (1 байт)
   
   
        в ответ на это сообщение модуль отсылает в эфир сообщение "данные исходящего слота".

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "регистрация входящего слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером в эфир как запрос на регистрацию входящего слота модуля в контроллере, структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "регистрация входящего слота"
            нагрузка:
                - номер входящего слота (1 байт)
   
   
        в ответ на это сообщение модуль отсылает в эфир сообщение "данные входящего слота".
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "данные исходящего слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается модулем в ответ на запрос "регистрация исходящего слота", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "данные исходящего слота"
            нагрузка:
                - ID слота (уникальный в рамках системы ID слота, 2 байта)
                - тип данных слота (температура и т.п., 2 байта)
                - флаги (наличие данных и пр., 1 байт)
                - длина данных слота (2 байта)
                - данные слота

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "данные входящего слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается модулем как ответ на запрос "регистрация входящего слота", структура:
       
        ID контроллера
        ID модуля
        Тип сообщения - "данные входящего слота"
        нагрузка:
            - ID слота (уникальный в рамках системы ID слота, 2 байта)
            - период публикации контроллером данных слота в эфир, миллисекунд (4 байта)
           
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "данные слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером в эфир для конкретного модуля, который зарегистрировал в контроллере свой входящий слот. Структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "данные слота"
            нагрузка:
                - ID слота (уникальный в рамках системы ID слота, 2 байта)
                - тип данных слота (температура и т.п., 2 байта)
                - флаги (наличие данных и пр., 1 байт)
                - длина данных слота (2 байта)
                - данные слота

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "запрос данных слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером в эфир для конкретного модуля, для запроса с него данных зарегистрированного исходящего слота. Структура:   

            ID контроллера
            ID модуля
            Тип сообщения - "запрос данных слота"
            нагрузка:
                - ID слота (уникальный в рамках системы ID слота, 2 байта)
               
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "ответ данных слота"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается модулем как ответ на сообщение "запрос данных слота", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "ответ данных слота"
            нагрузка:
                - ID слота (уникальный в рамках системы ID слота, 2 байта)
                - тип данных слота (температура и т.п., 2 байта)
                - флаги (наличие данных и пр., 1 байт)
                - длина данных слота (2 байта)
                - данные слота

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "запрос события"
    -------------------------------------------------------------------------------------------------------------------------------------------

        отсылается контроллером в эфир для конкретного модуля, структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "запрос события"
            нагрузка:
                - флаг, есть события или нет (1 байт)
               
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "публикация события"
    -------------------------------------------------------------------------------------------------------------------------------------------
       
        отсылается модулем в ответ на сообщение "запрос события", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "публикация события"
            нагрузка:           
                - Тип события (2 байта)
                - Длина данных события (2 байта)
                - Данные события
   
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "запрос конфигурации"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером на модуль, для запроса информации о его конфигурации, структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "запрос конфигурации"

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "данные конфигурации"
    -------------------------------------------------------------------------------------------------------------------------------------------
           
        отсылается модулем в ответ на событие "запрос конфигурации", структура:

            ID контроллера
            ID модуля
            Тип сообщения - "данные конфигурации"
            нагрузка:           
                - Кол-во слотов конфигурации (1 байт)
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "запрос слота конфигурации"
    -------------------------------------------------------------------------------------------------------------------------------------------

        отсылается контроллером на модуль для запроса определённого слота конфигурации, структура:

            ID контроллера
            ID модуля
            Тип сообщения - "запрос слота конфигурации"
            нагрузка:           
                - Номер слота конфигурации (1 байт)
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "данные слота конфигурации"
    -------------------------------------------------------------------------------------------------------------------------------------------
       
        отсылается модулем в ответ на сообщение "запрос слота конфигурации", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "данные слота конфигурации"
            нагрузка:           
                - Номер слота конфигурации (1 байт)
                - Тип слота (строковые данные, список и т.п.)
                - Длина имени слота
                - Имя слота
                - Длина данных слота (2 байта)
                - Данные слота конфигурации

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "сохранить слот конфигурации"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером на модуль для сохранения слота конфигурации, структура:

            ID контроллера
            ID модуля
            Тип сообщения - "сохранить слот конфигурации"
            нагрузка:           
                - Номер слота конфигурации (1 байт)
                - Длина данных слота (2 байта)
                - Данные слота конфигурации

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "слот конфигурации сохранён"
    -------------------------------------------------------------------------------------------------------------------------------------------
               
        отсылается модулем в ответ на сообщение "сохранить слот конфигурации", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "слот конфигурации сохранён"
            нагрузка:           
                - Номер слота конфигурации (1 байт)
                - Флаг успешности сохранения (1 байт)
                - Длина сообщения (2 байта)
                - Сообщение
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "запрос регистрации"
    -------------------------------------------------------------------------------------------------------------------------------------------

        отсылается контроллером в эфир для поиска модуля, находящегося в режиме регистрации, структура:
       
            ID контроллера
            ID модуля = 0xFF
            Тип сообщения - "запрос регистрации"
           
        если в эфире есть модуль, находящийся в режиме регистрации, он должен сохранить у себя ID контроллера, и ответить сообщением "регистрация завершена".

    -------------------------------------------------------------------------------------------------------------------------------------------
    сообщение "регистрация завершена"
    -------------------------------------------------------------------------------------------------------------------------------------------

        отсылается модулем в ответ на сообщение "запрос регистрации", структура:
       
            ID контроллера
            ID модуля
            Тип сообщения - "регистрация завершена"
       
 

Продолжение следует...

 

Код:

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

        обмен событиями происходит через контроллер, каждый модуль, желающий опубликовать в систему событие - ставит это событие во внутреннюю очередь, и отвечает по запросу контроллера.       
       
    -------------------------------------------------------------------------------------------------------------------------------------------
    событие "Установлена связь с GSM"
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        отсылается контроллером на широковещательный адрес, структура:
       
            ID контроллера
            ID модуля = 0xFF
            Тип сообщения - "событие"
            нагрузка:
                - ID модуля, инициировавшего событие
                - Тип события - "Установлена связь с GSM" (2 байта)
                - Длина данных события (2 байта)
                - Данные события
               
    -------------------------------------------------------------------------------------------------------------------------------------------
    событие "Пропала связь с модулем"
    -------------------------------------------------------------------------------------------------------------------------------------------
               
        отсылается контроллером на широковещательный адрес, структура:
       
            ID контроллера
            ID модуля = 0xFF
            Тип сообщения - "событие"
            нагрузка:
                - ID модуля, инициировавшего событие (в случае, если событие инициировано контроллером - 0xFF)
                - Тип события - "Пропала связь с модулем" (2 байта)
                - ID модуля, с которым пропала связь

    -------------------------------------------------------------------------------------------------------------------------------------------
    другие события
    -------------------------------------------------------------------------------------------------------------------------------------------
   
        список событий будет расширяться, выше приведена общая концепция событий, для понимания архитектуры.
               
    -------------------------------------------------------------------------------------------------------------------------------------------
    РЕГИСТРАЦИЯ МОДУЛЕЙ В СИСТЕМЕ
    -------------------------------------------------------------------------------------------------------------------------------------------
       
        поскольку при первичном сканировании в систему попадают только зарегистрированные модули, то регистрация в системе происходит по следующему алгоритму:
       
            - модуль переводится в режим регистрации кликом на кнопку, сигнализация моргающим светодиодом
            - контроллер переводится в режим регистрации кликом на кнопку, сигнализация моргающим светодиодом
            - контроллер сканирует эфир, рассылая сообщение "запрос регистрации", и как только получит ответ от модуля, находящегося в режиме регистрации, начинает с этим модулем общение
            - если регистрация не проходит какое-то разумное время - и контроллер, и модуль должны сигнализировать об этом, например, путём выключения светодиода
            - успешная регистрация сигнализируется путём включения светодиода, светодиод можно выключить кликом на кнопку регистрации
               
    -------------------------------------------------------------------------------------------------------------------------------------------
    Замечания по логике обмена
    -------------------------------------------------------------------------------------------------------------------------------------------
   
    Общение контроллера с модулями должно происходить по тем транспортам, по которым конкретный модуль был обнаружен в системе !!!
    Контроллер ВСЕГДА инициирует обмен, модули ВСЕГДА выступают слейвами!!!
    Модуль должен уметь принимать решение, что со входящего слота долго нет данных !!!
    Сообщения должны иметь разумную длину !!!
    Каждый транспорт сам разбирается, как передавать сообщение - целиком или бить на части - сборка пакета на совести транспорта !!!
    Если модуль не отвечает на N запросов - он выключается из работы !!!
    Каждый транспорт САМ обеспечивает проверку целостности данных !!!
    Общение в рамках системы сводится к обслуживанию пула сообщений и событий, конкретную логику работы - реализует каждый модуль самостоятельно !!!

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

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

 

Дмитрий добрый день, Поскольку в системе всего 4 МК и все писалось в разное время, то модули нанизывались как мясо на шампур, то есть цепочкой, каждый модуль знает о существовании правого и левого, соответственно имеет всего 2 канала передачи. 1 со 2 по uart, 2 с 3 NRF, 2 c 4 по uart.
На первом дисплей, GSM, WD за 2 и полив огорода, на втором баня, WD за 1 и 3 и nrf, на 3 nrf теплица, метеостанция, часть исполнительных устройств и WD за 4. 4 отвечает за привода форточек, имеет резервное питание, резервный датчик Т. и простой алгоритм управления ими на случай если 3 отключен по питанию. Передача данных идет постоянно полным пакетом телеметрии и метеоданных.
Если отправляется команда и она не для этого модуля она просто пробрасывается дальше. То есть если я послал SMS открыть форточку, команда пролетает на 4 модуль через 2 и 3 транзитом. Если надо полить в теплице, в пакете телеметрии 1 в позиции компрессор. 2 модуль видит что теплица запросила воды отправляет команду на первый модуль. Вся текущая информация о системе на втором модуле, Если открываю страницу дисплея "теплица", то первый модуль берет данные со второго, при этом 3 и 4 не запрашиваются.