Продолжаю публикацию статей по структуре «Умный дом» на основе локальной сети CAN. В этой статье описывается программа, которая записывается в каждый контроллер локальной сети.

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

В общем «не стреляйте в музыканта, он играет как может».

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

И попытался кратко описать основные моменты программы.

ПРИМЕЧАНИЕ — Везде, где упоминается «протокол» это проект ПРОТОКОЛА ОБМЕНА ДАННЫМИ

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

1. Основные принципы построения программы

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

• Каждый контроллер сети CAN может стать ответственным за связь с внешними по отношению к сети, устройствами (интернет, мобильный телефон и так далее), в случае если станет неисправно устройство подключенное через модуль Ethernet.

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

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

2. Степень реализации протокола на данный момент

• Организация обмена данными в сети CAN (TWAI). Сканирование сети по нажатию кнопки на устройстве подключенном к Ethernet, получение информационных сервисов всех включенных в сеть устройств.

• Организация обмена данными по сети Ethernet.

• Запуск mqtt client через соединение web‑socket security

• Работа сети CAN(TWAI) по сценариям и событиям.

• Реализована работа сети CAN согласно протоколу для двух сервисов типа: блок 2 реле (код 0×210) и кнопки/переключатели (код 0×0A0).

3. Принципы построения программы

3.1 Программа является единой для устройств сети CAN, как "master" так и "slave". Понятия "master" и "slave" условно, в первом случае оно означает устройство ответственное за связь с внешним миром, а во втором все остальные устройства сети (но роли могут поменяться). Работа программы определяется свойством "подчиненность" задаваемым в информационном сервисе устройства. Кроме того в информационном сервисе каждого устройства содержатся перечисление функциональных типов выполняемых устройством, по наличию которых производится автоматическое конфигурирование программы работы устройства с датчиками и исполнительными устройствами.

Программа основана на принципе многозадачности с использованием очередей запросов и семафоров.

3.2 Алгоритм работы

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

Затем устройство с локальным номером 1, которое подключается к роутеру через Ethernet, запускает программу установки драйвера Ethernet. Если драйвер установлен правильно (модуль Ethernet работает), запускается программа получения ip‑адреса от роутера и включается светодиод «WORK». В случае неудачи создания соединения по протоколу TCP или потеря связи с роутером, светодиод «WORK» выключается.

По кратковременному нажатию кнопки «INIT» устройства «master» происходит опрос подключенных в сеть CAN устройств «slave» в режиме разделения во времени, причем в связи с неустойчивым приемом данных сканирование сети происходит несколько раз при суммировании адресов ответивших устройств. По результату опроса составляется список обнаруженных устройств. Затем у этих устройств последовательно запрашиваются ИНФОРМАЦИОННЫЕ СЕРВИСЫ. Сервисы передаются в пакетном режиме: каждая характеристика сервиса это отдельный кадр данных CAN. Полученная информация заносится во флэш-память устройства "master", откуда может быть востребована дальнейшей работы сети или по команде внешнего устройства (сервер, сотовый телефон).

ПРИМЕЧАНИЕ

1. Все запросы данных в сети CAN повторяются несколько раз при отсутствии ответа.

2. Все данные передаваемые в пакетном режиме содержат номер кадра данных и проверяются приемником на соответствие в порядке очередности.

3. При потере хотя бы одного кадра данных все данные запрашиваются повторно, возможно несколько раз.

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

5. При опубликовании «события» подчиненным устройством согласно сценария всегда производятся повторы оговоренное число раз.

Каждое устройство хранит в отведенной области памяти‑nvs «profile» в пространстве имен «device_inf» информационный сервис. Кроме информационного сервиса там же хранятся сервисы функциональности, расположенные в пространстве имен типа «type*», где * — это номер функциональности в списке перечисления кодов информационного сервиса.

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

• таблица параметров устройства (до 8 параметров на каждый из возможных 8 типов функциональности);

• таблица событий сети CAN на которое подписано устройство(до 16 событий на каждый из возможных 8 типов функциональности);

• таблица исполнения по этим событиям (по коду действия на каждое из возможных 16 событий на каждый из возможных 8 типов функциональности).

Для связи между номером функциональности в списке перечисления кодов информационного сервиса кодом функциональности служит таблица в ОЗУ устройства, где номер ячейки это код типа, а содержимое первый индекс таблиц для обслуживания сервисов типа.

На каждый тип функциональности отведен свой файл в программе для инициализации при сбросе и драйвера для работы с подключаемыми датчиками/исполнителями.

Для исключения сбоев при пропадании питания, при изменении любой из характеристик устройства она заносится в nvs‑память.

Кроме того устройство мастер отслеживает обмен данными по сети CAN и всю информацию заносит также в отведенные для устройств разделы nvs-памяти.

4. Структура программы и рабочие инструменты с помощью которых была написана

Программа написана в среде программирования ESP‑IDF v5.4.3 на языке C/C++. Для написания программы использовался в качестве редактора текста VSCode с установкой минимального набора расширений: Russian Language Pack for Visual Studio Code и C/C++ Extension Pack.

Отладка программы производилась через окно монитора ESP‑IDF5.4 CMD проявляющего при установке инструментов ESP‑IDF в режиме ручной установки, Toolchain, согласно источнику https://docs.espressif.com/projects/esp‑idf/en/v5.4.3/esp32c6/get‑started/index.html

Программа написана в традиционном стиле языка С с добавлением возможностей языка С++. Так как ESP‑IDF основано на операционной системе реального времени FreeRTOS, то в программе используется многопоточность/многозадачность и значит такие понятия как: задачи, очереди, семафоры и так далее

Структура программного проекта соответствует требованиям среды программирования ESP‑IDF изложенным в источнике: руководство по API, система сборки https://docs.espressif.com/projects/esp‑idf/en/v5.4.3/esp32c6/api‑guides/build‑system.html.

Структурно проект имеет следующий вид:

Папка проекта:

Скрытый текст

папка ”components”:

папка ”button”

папка ”controller_can”:

CmakeLists.txt

sdkconfig.defaults

partitions.csv

nvs_partition_gen.py

profile.csv

папка ”main”:

папка ”certs”

CmakeLists.txt

app_main.c

app_priv.h

app_const.h

app_init.c

app_driver.c

app.utilit.c

app_mqtt_wss.c

ethernet.c

message.c

CAN.c

MAKE_PARAMETR.c

TYPE.c

TYPE_0A0.c

TYPE_210.c

Папка ”components” содержит программные компоненты необходимые для компиляции программы и взятые из внешних источников. Папка ”button” позаимствована из ранней версии проекта ”esp-jumpstart” и содержимое можно скачать из моего репозитория.

Папка ”controller_can” представляет собой собственно программный проект и включает следующие файлы:

• “CmakeLists.txt” содержит указания для CMake , который настраивает проект для сборки. Имеет три обязательные части + список каталогов для поиска компонентов.

  Скрытый текст

  cmake_minimum_required(VERSION 3.5) include($ENV{IDF_PATH}/tools/cmake/project.cmake) set(EXTRA_COMPONENT_DIRS ${CMAKE_CURRENT_LIST_DIR}/../components) project(controller_can)

• “sdkconfig.defaults” конфигурация SDK проекта по умолчанию. Ниже приведено содержимое файла с объяснением каждой строки.

  Скрытый текст

  CONFIG_IDF_TARGET="esp32c6"#используемый тип микросхемы

  CONFIG_ESPTOOLPY_FLASHSIZE_8MB=y#размер флэш-памяти

  #--нижеперечисленное относится к разбивке флэш-памяти---

  CONFIG_PARTITION_TABLE_CUSTOM=y

  CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions.csv"

  CONFIG_PARTITION_TABLE_FILENAME="partitions.csv"

  CONFIG_PARTITION_TABLE_OFFSET=0x8000

  CONFIG_PARTITION_TABLE_MD5=y#наличие контрольной суммы для проверки таблицы

  #--нижеперечисленное относится к ETHERNET--

  CONFIG_ETH_ENABLED=y

  CONFIG_ETH_USE_SPI_ETHERNET=y

  CONFIG_ETH_SPI_ETHERNET_W5500=y

  #--нижеперечисленное относится к Websocket--

  CONFIG_WS_TRANSPORT=y #установлено по умолчанию

  CONFIG_WS_BUFFER_SIZE=1024 #установлено по умолчанию

  #--нижеперечисленное относится к MQTT--

  CONFIG_MQTT_PROTOCOL_311=y #установлено по умолчанию

  CONFIG_MQTT_TRANSPORT_SSL=y #установлено по умолчанию

  CONFIG_MQTT_TRANSPORT_WEBSOCKET=y #установлено по умолчанию

  CONFIG_MQTT_TRANSPORT_WEBSOCKET_SECURE=y #установлено по умолчанию

ПРИМЕЧАНИЕ - Перед первой компиляцией необходимо задать целевое устройство в окне монитора ESP-IDF5.4 CMD командой: idf.py set-target esp32c6.

• “partitions.csv” таблица разбивки флэш-памяти. Ниже представлен макет таблицы с учетом того, что смещение раздела прошивки должно быть выровнено на 64 КБ, начальные 36 КБ (9 секторов) зарезервированы для загрузчика и таблицы разделов.

  Скрытый текст

  # Name, Type, SubType, Offset, Size, Flags

  nvs, data, nvs, 0x9000, 0x6000,24K,

  otadata, data, ota, 0xf000, 0x2000,8K,

  phy_init, data, phy, 0x11000, 0x1000,4K,

  ota_0, app, ota_0, 0x20000, 3000K,

  ota_1, app, ota_1, 0x310000, 3000K,

  profile, data, nvs, 0x5FE000, 0x6000,24K,

  user_nvs, data, nvs, 0x604000, 0x6000,24K,

  net_dev, data, nvs, 0x60A000, 0x6000,24K,

  device1 data, nvs, 0x610000, 0x6000,24K,

  ..................................................

  device63 data, nvs, 0x784000, 0x6000,24K

  Область памяти «nvs» предназначена для энергонезависимого хранения пар ключ‑значение, в частности данных Wi‑Fi.

  Область памяти «otadata» это раздел данных OTA(обновления прошивки), в котором хранится информация о выбранном в данный момент слоте приложения OTA.Когда используется OTA, раздел данных OTA определяет, какой слот приложения должен загружать загрузчик.

  Область памяти «phy_init» предназначена для хранения данных инициализации PHY. Это позволяет настраивать PHY для каждого устройства, а не во встроенном ПО. В конфигурации по умолчанию раздел phy не используется, а данные инициализации PHY компилируются в само приложение

  Области памяти «ota_0» и «ota_1» используются для обновления прошивки программы. При использовании OTA приложение должно иметь как минимум два слота для приложений OTA.

  Область памяти «profile» предназначена для энергонезависимого хранения пар ключ‑значение, в ней будут храниться профиль устройства.

  Область памяти «user_nvs» предназначена для энергонезависимого хранения пар ключ‑значение для данной программы.

  Область памяти «net_dev» предназначена для энергонезависимого хранения пар ключ‑значение для записи данных общих для сети CAN.

  Область памяти «device1 ‑: device63» предназначена для энергонезависимого хранения пар ключ‑значение для записи данных профилей устройств подключенных к сети CAN.

  Более подробно о создании таблицы разделов в источнике.

• Следующий файл «nvs_partition_gen.py» не компилируется при создании исполняемого кода, а предназначен для формирования в бинарном коде личного профиля для каждого устройства.

  ^{Процесс создания области памяти хранения данных профиля устройства описан ниже.}

  Скрытый текст

  Откройте в главной директории проекта файл profile.csv с помощью редактора "блокнот", а если его нет создайте в соответствии с требованиями изложенными в https://github.com/espressif/esp-idf/tree/v5.4/components/nvs_flash/nvs_partition_generator файл с расширением .csv со следующим содержимым:

  key,type,encoding,value

  d_inf,namespace,,

  s/n,data,string,"00001"

  obey,data,string,"master"

  name_d,data,string,"device_one"

  place,data,string,"no_name"

  v_program,data,string,"v1"

  type_c,data,string,"070 210 0A0 220#"

  • - где выражение в " " задается серийный номер, тип изделия и т. д.

    • Созданный/измененный файл превращается в бинарный файл с помощью команды:

      "python nvs_partition_gen.py generate profile.csv profile.bin 0x6000"

      • Затем записывается утилитой esptool.py в NVS память микропроцессора. Например команда записи через порт вывода "com8" во "flash память" с адреса "0x5FE000" файла "profile.bin":

        "esptool.py -p com8 write_flash 0x5FE000 profile.bin"

      ВНИМАНИЕ ‑ Через USB порт модуля ESP32C6 не происходит запись с помощью утилиты esptool.py. Для записи необходимо использовать инструмент для загрузки Flash, ссылка на описание и файл для скачивания: https://docs.espressif.com/projects/esp‑test‑tools/en/latest/esp32/production_stage/tools/flash_download_tool.htm

• «profile.csv» файл формируется индивидуально для каждого устройства сети в соответствии с требованиями изложенными выше.

• папка «certs» содержит корневой сертификат MQTT сервера (брокера). Как получить сертификат непосредственно от сайта, см. https://kotyara12.ru/iot/ssl‑arduino/. Я использую брокера wqtt.ru, поэтому сертификат в папке от него.

• “CmakeLists.txt” в папке ”main” файл для управления компонентами регистрирует все файлы на языке Си входящие в проект и сертификат брокера MQTT.

  Скрытый текст

  idf_component_register(SRCS "app_main.

  "app_init.c"

  "ethernet.c"

  "app_utilit.c"

  "app_driver.c"

  "app_mqtt_wss.c"

  "message.c"

  "CAN.c"

  "MAKE_PARAMETR.c"

  "TYPE.c"

  "TYPE_0A0.c"

  "TYPE_210.c"

  INCLUDE_DIRS "."

  EMBED_TXTFILES

  "certs/wqtt.pem")

  5. Описание файлов составляющих программу

5.1 “app_main.c” главный файл программы

Краткое описание функций этого файла.

Программа всегда запускается с функции:

• «void app_main()» расположенной в этом файле. В ходе выполнения данной функции, последовательно настраивается работа устройства:

  • инициализируются используемые выводы контроллера;

  • получение из информационного сервиса профиля устройства данных и конфигурирование устройства в связи этим, как устройство подключенное к Ethernet или нет;

  • инициализация прерывания при нажатии кнопки «INIT»;

  • создание очередей и семафоров для организации работы с создаваемыми задачами обмена информацией по шине CAN (TWAI).

  • создание задач для ОС (задача приема сообщения по шине TWAI, задача передачи сообщения по шине TWAI, задача контроля и управления работой контроллера);

  • создание и настройка сторожевого таймера задач, необходимого для исключения зависания программы и подписка задачи контроля на этот таймер;

  • если локальный номер устройства 1, то инициализировать: Ethernet driver, сетевой интерфейс TCP/IP.

  • Далее организовать задержку во времени на получение IP адреса и после этого запустить mqtt client через соединение web socket security.

  • в завершении инициализировать интерфейс CAN (TWAI).

    ПРИМЕЧАНИЕ - При написании программы обмена информацией по TWAI использовалось описание в ESP-IDF: https://docs.espressif.com/projects/esp-idf/en/v5.4.1/esp32c6/api-reference/ peripherals/twai.html. Описание компонента. А за основу взят пример из github.

• Объявление глобальных переменных. Кроме вышеуказанных таблиц, в ОЗУ устройства резервируется место под таблицы имен для работы с nvs‑памятью. Это связано с тем, что для записи информации в nvs‑память можно использовать ключи‑наименования только типа «const».

• static void twai_receive_task(void *arg) задача чтения сообщений передаваемых по сети CAN. Вызывается для обработки сообщений полученных из интерфейса TWAI. Порядок работы зависит от типа подчиненности устройства и режима работы (flag_mode).

• static void twai_transmit_task(void *arg) задача отправки сообщения в сеть CAN. Вызывается для формирования и отправки сообщений в интерфейс TWAI. Режим работы полностью определяется данными заложенными в очереди запросов на обработку.

• static void ctrl_task(void *arg) задача контроля работы всех задач. Осуществляет контроль над работой всего контроллера, находится в режиме бесконечного цикла. С помощью семафора и очереди запросов осуществляет управление обменом данными по сети CAN. А также инициализирует обмен данными по сети Ethernet/WSS/MQTT. Алгоритм работы программы зависит от подчиненности устройства, а также наличия прерываний от сети TWAI и запроса на обработку внешней команды (flag_mode == 5).

• static void eth_event_handler обработчик событий для Ethernet.

• static void got_ip_event_handler обработчик события получения IР адреса.

5.2 Заголовочные файлы (*.h)

• app_priv.h содержит объявления функций для многократного использования в разных *.c файлах.

• app_const.h содержит константы, которые может менять пользователь до компиляции программы, с целью изменения ее настроек.

5.3 app_init.c

Файл содержит несколько функций для инициализации устройства.

• void init_GPIO() данная функция вызывается для инициализации входов/выходов микроконтроллера.

• void get_DeviceInf() функция получения из информационного сервиса данных и инициализация выполняемых типов функциональности для данного устройства (коды типа функциональности находятся в последней строке информационного сервиса).

• void read_inf_service() данная функция вызывается для чтения из флэш‑памяти информационного сервиса и записи в буфер для выдачи в TWAI.

• void init_list_slaves() данная функция вызывается для инициирования раздела флэш‑памяти «net_dev» с общей информацией для сети TWAI и записи в него списка подключенных устройств.

• void init_inf_service_slave функция инициализации и записи в nvs‑память информационного сервиса подчиненного устройства.

• void read_prof_slave функция чтения профиля подчиненных устройств из памяти.

• void read_list_slaves() функция чтения списка подчиненных устройств.

5.4 app_driver.c

Программа обработки нажатия кнопки «INIT». Работа программы построена на обработке прерывания от вывода микроконтроллера к которому подключена кнопка. Программа взята из ранней версии проекта Espressif «Jumpstart» и подверглась минимальным переделкам. Программа написана на языке С++ и основная ее часть содержится в главной директории, в папке «components».

5.5 app_utilit.c

Файл содержит программы утилиты используемые в основной программе.

• long htol функция преобразования числа в шестнадцатеричном коде представленного в символьном отображении в двоичный код размерностью 32 бита(тип long).

• void form_cadr функция преобразования строки в кадр данных и записи в буфер для передачи в TWAI.

• void form_many_cadr функция преобразования строки в несколько кадров данных.

• int true_data() функция проверка правильности полученного пакета данных от сети TWAI на соответствие номера полученного пакета данных с номером пакета внутри.

• char *change_profile_nvs функция записи/чтения в nvs‑память измененных данных типа функциональности устройства.

5.6 app_mqtt_wss.c

Программа создание и запуск задачи соединения клиента с брокером MQTT через wss (websocket secure).

Для надежного приема/передачи данных использовать уровень качества обслуживания QoC 1 (подтвержденная доставка) с запоминанием сообщения до замены его новым по тому же топику.

По умолчанию размер буферов приема/передачи установлен в файле sdkconfig - 1024 байт(по умолчанию).

Адрес в интернете (uri), порт, сертификат, имя пользователя, пароль, идентификационный номер клиента - предоставляется брокером и записывается в программе, файл "app_mqtt_wss.c" конфигурация mqtt.

Кроме того в конфигурацию mqtt заносятся следующие настройки:

- keepalive = 30 сек. максимальное время, в течение которого клиент или брокер могут не отправлять управляющий пакет;

- формирование сообщения для подписанных пользователей при отключении от брокера LWT (topic = "status", msg = "off"). Сообщение отсылается через время равное: 1.5 х keepalive;

При установлении соединения (новый сеанс) первым посылается сообщение: topic = "status", msg = "on", означающее что система подключилась.

При написании программы клиента MQTT с подключением через протокол WebSocket Secure использовалось описание ESP-IDF:

https://docs.espressif.com/projects/esp-idf/en/v5.4.2/esp32c6/api-reference/protocols/mqtt.html

Также протокол MQTT хорошо описан в: https://circuitlabs.net/courses/esp32-masterclass/

А за основу взят пример из githab:

https://github.com/espressif/esp-idf/tree/v5.4.1/examples/protocols/mqtt/wss

5.7 ethernet.c

Программа драйвера ethernet на основе SPI модуля W5500.

При написании программы подключения Ethernet через модуль по SPI использовалось описание в ESP-IDF: https://docs.espressif.com/projects/esp-idf/en/v5.4.1/esp32c6/api- reference/network/esp_eth.html. А за основу взят пример из github: https://github.com/espressif/esp-idf/tree/v5.4.1/examples/ethernet/basic.

Файл программы содержит только одну функцию:

• esp_err_t eth_init инициализации драйвера.

5.8 message.c

Программа для работы с сообщениями протокола MQTT. Содержит две функции:

• void mqtt_msg_in функция анализа сообщения полученного от mqtt-сервера.

• void event_on_mqtt функция формирования сообщения о событии в сети CAN для отправки в MQTT, а также запись события во флэш память.

5.9 CAN.c

Программа драйвера сети CAN (TWAI). Содержит следующие функции:

• void init_CAN(gpio_num_t TX, gpio_num_t RX) функция вызывается для инициализации интерфейса CAN.

• void message_t_CAN функция вызывается для передачи данных по интерфейсу CAN.

• void remote_frame функция вызывается для запроса данных от устройства сети CAN (кадр удаленного запроса).

• void event_processing(uint64_t event) функция вызывается для обработки событий в сети CAN.

• void com_processing функция вызывается для обработки команды изменения параметра устройства.

• void name_script_processing функция вызывается для обработки команды изменения имени или сценария.

5.10 MAKE_PARAMETR.c

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

• void make_parametr(uint16_t kod_make, uint16_t value_par) функция выполнения действий при обращении по изменению параметра функциональности. Первый параметр функции, это код обработки = код функциональности + номер параметра << 11. Второй параметр, это величина параметра функциональности.

Так как задействован пока только одна исполнительная функциональность типа «0х210», присутствует только исполнение по двум реле.

5.11 TYPE.c

Программа содержит функции общие для всех типов функциональности. Содержит одну функцию:

• void read_service_type(uint8_t num_tab) шаблон чтения сервиса типа функциональности из nvs-памяти в выделенную таблицу в памяти ОЗУ.

5.12 TYPE_0A0.c

Программа где собраны в одном месте функции относящиеся только к данному типу функциональности «0А0» (драйвера и прочее...).

Тип функциональности «0А0» это две кнопки, активный уровень лог. 0. По первому нажатию параметр функциональности устанавливается в «1», по второму нажатию устанавливается в «0».

Программа содержит следующие функции:

• void push_btn_cb1p(void *arg) эта функция вызывается при отпускании первой кнопки.

• void push_btn_cb2p(void *arg) эта функция вызывается при отпускании второй кнопки.

• void init_type_0A0(uint8_t num) данная функция вызывается для инициализации входов/выходов и шаблона сервиса типа в nvs памяти.

5.13 TYPE_210.c

Программа где собраны в одном месте функции относящиеся только к данному типу функциональности «210» (драйвера и прочее...).

Тип функциональности «210» это два реле, включение лог.1.

Программа содержит следующие функции:

• void init_type_210(uint8_t num) функция вызывается для инициализации входов/выходов и шаблона сервиса типа в nvs памяти, num от 0 до 8.

• int type_210_make функция обрабатывает команду полученную извне для данного устройства.

ПРИЛОЖЕНИЕ

Работа с MQTT

1 Структура формирования топиков

Применяемые для работы с разработанной системой топики имеют два типа:

- 1 тип. Топики управления начинаются с com/ (префикс), брокером не запоминаются;

- 2 тип. Топики информации (исполнения) начинаются с inf/, запоминается брокером флаг «retain”;

Топики имеют следующий вид:

- первое число после префикса, это локальный номер контроллера в системе.

- второе число между двумя «/», это код типа функциональности контроллера (их может быть до 8 шт. + информационный сервис (0х000).

- третье значение указывает на обращение к параметрам p или к сценариям s или наименованиям n

- четвертое это номер параметра или сценария или имени. 1 имя это ”type_name”(для инф.сервиса «name_d)», 2 имя это ”name_user”(для инф.сервиса «place»), 3 имя это ”name1p”, 4 имя это ”name2p” и т.д.

Например:

topic “com/1/210/p/1” data “1” //означает команду на включение 1 реле;

topic “inf/1/210/p/1” data “1” //означает информацию о включении 1 реле;

topic “com/1/210/n/1” data “two relays” //запись наименования типа;

topic “com/1/210/n/2” data “lighting” //запись имени присвоенного пользователем;

topic “com/1/210/n/3” data “general” //запись имени первого параметра - «общее»;

topic “com/1/000/n/1” data “device_one” //означает команду на изменение имени устройства;

topic “com/1/000/n/2” data “no_name” //означает команду на изменение имени присвоенного пользователем;

topic “inf/1/000/n/1” data “device_one” //означает информацию об имени устройства;

topic “com/3/210/s/1” data “{”event”:{“2/A0/p/2”:”1”},”make”:{“1”:”1”}}” //означает запись в контроллер системы с локальным номером 3, в тип функциональности «210», следующего сценария: при появлении сигнала на входе2 второго контроллера, включить реле1.

Существует особый топик: inf/status.

При подключении к брокеру по данному топику посылается сообщение «on», а при разрыве соединения системы с брокером, самим брокером формируется сообщение «последней воли»: ”off”.

Инструменты

В качестве инструментов по поддержке при отладке данного способа обмена информацией могу порекомендовать следующие программы и приложения:

• в качестве брокера‑сервера использовать https://www.wqtt.ru/, который имеет бесплатный период 30 дней и платный по 300 ₽ в год;

• в качестве программы отображения/управления через брокер‑сервер использовать приложение для сотового телефона «MQTT client», пока его еще можно скачать через Google Play;

• с помощью вышеуказанной программы не удастся занести в систему сценарии. Поэтому для записи сценариев советую использовать программу устанавливаемую на компьютер: «MQTT explorer» (скачать из https://mqtt‑explorer.com/ ). Описание как работать с этой программой приведено здесь.