Универсальная сеть умных устройств smartlets

axill
Offline
Зарегистрирован: 05.09.2011

автоматизация дома хобби
начинал с установки и настройки дома сети zwave
потом подключался к проекту mysensors который стартовал от контроллера micasaverde для zwave

везде что то не устраивало до конца
захотелось сделать что то свое
проект исследовательский и хоббийный, буду рад соучастникам

основные принципы:
 

  • формат сообщений никак не привязан ни к используемой платформе ни к используемому физическому/логическому железу через которое передаются сообщения
  • отсюда следует отсутствие привязки к какой либо платформе для чего была выделена отдельная библиотека stavrp - сокращение от stm + avr + plus (C++), хотя сейчас список платформ уже несколько шире и в общем то может быть расширен
  • для поддержки первых двух подходов программная часть разделена на несколько слоев, все кроме последнего платформо независимы или условно независимы, от верхнего к нижнему:
    • Application - конечное приложение, их может быть несколько в паралелль или в связке. Приложение имеет стандартные интерфейсы для получения и отправки сообщений, может участвовать в фильтре входящих и исходящих сообщений - это позволяет расширять базовый функционал путем plug&play нужных Application, добавляя такой функционал как Ping и автоматическое назначение адресов, также интерфейс к таймеру и к основному циклу. Цель библиотеки, чтобы вся суть конечного устройства была сосредоточена на разработке приложений. Пример приложения - термостат, т.е. считывающая данные с датчика температуры, отсылающая команды на включение локального или удаленного реле и управляемое по сети через сообщения
    • Node - это инфраструктура для запуска приложений, организует все доступные приложениям интерфейсы. Node может быть одна или несколько на устройство, но одна нода на один физический интерфейс передачи данных. Т.е. один интефейс - одна нода, два интерфейса - две ноды и т.д. Адрес устройства соотносится с нодой, может быть один для всех нод устройства или разные. Рассматривается сейчас три типа Node: простая нода, мост (bridge) - связка двух разных физических сред передачи, router - маршрутизатор между многими подсетями в однородной или разнородной физической среде передачи
    • Interface - логический уровень интерфейса к физическому уровню для Node. Рассматриваются сейчас два типа стандартных интерфейсов (другое название диспетчер) - P2P для сети равноправных устройств и Master&Slave для сетей с выделенным мастером
    • Translator - преобразователь формата сообщения между логическим уровнем понятным (и стандартным) для приложений и физическим уровнем оптимальным для передачи через физический интерфейс. Например для сред без гарантированной передачи стандартное сообщение инкапсулируется в другое сообщение с преамбулой и контрольной суммой
    • Driver - собственно единственный явно платформо зависимый и завязанный на среду передачи. он дает связку для Translator в обе стороны между логическим уровнем приложений и физической средой передачи. Пример драйвера - UART
  • Исключение обязательного центрального контроллера. Каждое устройство может самостоятельно общаться с любым другим устройством путем настроенной прямой адресации или через широковещательные сообщения. При этом центральные устройства могут добавлять дополнительные сервисы и возможности.

для гибкости при сохранении оптимального использования ресурсов интенсивно используется С++11 с шаблонами
это позволяет гибко настраивать конкретное приложение под конкретное железо в основном в процессе компиляции

Адресация глобальная, вне зависимости от того какая среда передачи использована. Можно адресовать глобально или локально любое устройство.
Адресация 16 бит, организована как 4094 сегмента по 16 устройств и два сегмента широковещательных сообщений - один для глобальной сети, второй для локальной.
Локальная сеть - это устройства подключенные к одной физической среде где они могут без посредников общаться друг с другом.
На локальной сети может быть один или несколько сетевых сегментов

Стандартный заголовок (10 байт) сообщения универсальный для любых задач:

struct Header {
   // --- message data
   uint8_t             size;         // message data length in bytes excluding header
   Attributes          attributes;
   ID                 rx;            // id of device this message is sending to
   ID                 tx;            // id of device this message is sended from
   Type              type;         // type of the message
   Smartlets::uint16   sid;             // message sequence number
   // --- methods
   Header() : size(0), attributes(), sid(0) {}
};

Остальная часть сообщения специфична для каждого типа сообщений определяемых полем type. Это поле 16 бит.
Максимальный размер сообщения определяется настройками при компиляции и задает некую планку тех сообщений которые могут приниматься и пересылаться:

template <int payload_size>
struct Message : public MessageBase {
   // --- static
   static const int data_maxsize = payload_size - sizeof(header);
   // --- message data
   DataArray<data_maxsize>   data;
    // --- methods
    Message() : MessageBase() {}
    Message(const MessageBase& msg) : MessageBase(msg) {}
};

Использование шаблона здесь позволяет минимизировать требования к ресурсам на конкретном устройстве не вводя никаких принципиальных ограничений. Минимальное требование для устройств на базе 8ми битных МК - 8Кб флэш и 1Кб RAM

Сообщения позволяют следующие базовые функции сети:
 

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

что сейчас реализовано:

  • ядро для написание кода для устройств на базе esp8266 в среде ардуино и пример термостата. Ядро содержит в себе bridge node которая также позволяет связывать устройство подключенное к esp по UART связываться по TCP/IP с router и с любыми сегментами подключенными к этому же router. Т.е. можно сделать два локальных сегмента на МК например на RS485 и связать их друг с другом через ESP по wifi и их же завязать на openhab
  • похожее ядро отлаживаю для STM32 с W5500, пока не стабильно. Цель таже что с ESP только по проводам
  • все программные уровни для STM8S с драйверами для трехпроводной P2P сети (питание + сигнальный) на базе драйвера из 4-х резисторов и одного транзистора на скорости 2000 бод - называю ее W3P (wire 3 pole)
  • bridge на STM8S между W3P и UART, позволяет связывать любую сеть W3P с router
  • linux router - серверное приложение которое связывает между собой все bridge с интерфейсом к TCP/IP (сейчас это ESP8266 и STM32&W5500), кроме того в нем интерфейс к MQTT, позволяет маршрутизировать сообщения туда и обратно в формате JSON. Серверов может быть несколько. сейчас поддерживается один основной и один резервный

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

Библиотеки опубликованы https://github.com/axillent
stavrp - C++ библиотека для поддержки платформозависимого кода
smartletsp - C++ библиотека сети устройств

swilib - обертка для разработки в среде ардуино

публикую на двух форумах, здесь копия http://forum.easyelectronics.ru/viewtopic.php?f=17&t=37183

axill
Offline
Зарегистрирован: 05.09.2011

Добавил Linux Router https://github.com/axillent/swi_appserver

-NMi-
Offline
Зарегистрирован: 20.08.2018

Идея не плоха. Одно время хотел так сделать на радиомодулях (не 433мГц, а те, которые реально с pll и с возможностью переключения по каналам)  , но, наверное, мозга не хватило.

От себя дополню - для начала нужен арбитраж, иначе много устройств на одной шине приведут к коллизиям. Потом необходим приоритет устройства. Далее желательна маршкутизированность на уровне ip ttl

Ну... и...должен!!! быть ГЛАВНЫЙ, кто управляет этим всем :)))

axill
Offline
Зарегистрирован: 05.09.2011

арбитраж нужен в сетях Master&Slave, в сетях P2P он не нужен

в том часть идеи - в основе системы нет жестких ограничений что и как должно быть сделано и одновременно определен стандарт интерфейса к приложению

это значит, что приложение написанное для сети Master&Slave на RS485 будет без переписывания работать через Wifi на ESP8266