Хабрахабр

С новым годом, с новым MQTT/UDP

Привет.

Как я уже писал недавно (Первая краткая статья о MQTT/UDP), MQTT/UDP — протокол на базе MQTT, но:

  • Ходит поверх UDP broadcast (не нужен брокер, почти не нужна конфигурация)
  • До неприличия простой в реализации (10 строк на си + UDP/IP стек — и вы отправляете данные с сенсора)
  • Все слышат всех

В некотором смысле это CAN, но поверх Ethernet-а.

Умом это назвать было бы избыточно, но — свет и климат автоматизированы. Зачем.
Моя квартира реально несколько лет живёт под управлением системы типа «дом не совсем олигофрен». Две стенки стойки заняты почти до пола. Чтобы представить себе масштаб бедствия — система занимает полную битком набитую стойку о 19 дюймах ширины и двух метрах высоты.

Несколько лет эксплуатации показали: оно и верно. Когда я всё это проектировал, вопрос отказоустойчивости стоял на первом месте. Рано или поздно. Отказывает всё. Вот только электромеханические реле ещё пока не отказывали, а именно на них последний эшелон защиты от отказа.

В силу естественного течения жизни, моего любопытства и насущных потребностей, в системе живут обычный Юникс на обычном PC, ПЛК Овен, Raspberr+Orange PI, модули на Atmega, модули на базе NodeMCU (ESP8266), и всё это ходит друг к другу через modbus 485, modbus TCP, http, и сбоку висит неприкаянный MQTT брокер, как наследие неудачной попытки перейти на него всем табором. Следующая после отказоустойчивости проблема — зоопарк.

Во-первых, для части железа он тяжеловат или сложноват. Почему попытка перейти на MQTT неудачна. А ведь потом надо и отладить. На том обломке Паскаля, который прячется в CodeSys ПЛК написать MQTT может только мазохист. Но и это не вся беда. Аналогично на atmega: запихать можно, но тесно.

1. MQTT как он есть (а заимплеменчен везде 3. Эффект от этого маразма фееричен — тот же OpenHAB не может отправлять и получать данные в MQTT под одним и тем же именем. 1) настаивает на том, чтобы посылать PUBLISH пакет (то есть наше сообщение в сторону брокера) всем получателям, в том числе и отправителю. А именно так должна быть организована связь ПЛК, в котором живёт основное управление светом, ОпенХАБа, который управляет светом с веб-интерфейса и мобильного приложения, и смарт-выключателей, которые я хотел бы иметь возможность добавлять там и тут. Это означает, что организовать на базе MQTT шину (несколько модулей, которые обновляют значение одного и того же объекта и пользуются им же) нельзя. То есть, конечно, и эту проблему можно обойти, но фактически это означает построить свой протокол ПОВЕРХ MQTT, а это уже кажется перебором.

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

Я же умозрительно отвечал ему, что для IoT оный UDP БОЛЕЕ надёжен, чем TCP: при 50% потерь пакетов в сети TCP не просто ляжет, а ляжет ВООБЩЕ, а температурный датчик, посылающий измерения по UDP, просто потеряет половину отсчётов, что скажется на работе системы примерно никак. После прошлого поста на Хабре один из читателей долго упрекал меня ненадёжностью протокола UDP. Вообще.

Однако, новогодние каникулы и даны человеку для того, чтобы допив шампанское спросить себя: а положим сегодня домашнюю локалку на лопатки? Но это было умозрительно. А что бы и нет.

Одна сторона шлёт последовательные пакеты без паузы между пакетами, сколько может. Я взял MQTT/UDP и написал примитивный тест. Эксперимент был прост: запускаем это издевательство, а параллельно два HD телевизора показывают кино из интернета, а настольный комп пишет на NAS огромный файл. Вторая считает скорость и потери пакетов.

Я ждал всего, но… максимум потерь на UDP достиг целого полупроцента, а оба телевизора остановили показ. Оцените итог. В реальной домашней сети надёжность доставки UDP близка к абсолюту. Так что я ещё был пессимистом. Сложности немного, а вопрос снимает совсем. Тем не менее, версию с подтверждениями и перепосылками пакетов я, видимо, сделаю.

Впрочем, опять же, задача цифровой подписи пакетов в issue tracker'е присутствует, и я уже понимаю, как расширить MQTT-шные пакеты под её реализацию. Второй вопрос — секьюрити, но, право, если мне взломают домашнюю сеть, потеря данных с датчиков температуры — последнее, о чём я буду горевать.

В общем, я планирую по первой паре устройств в домашней сети перейти на MQTT/UDP буквально на днях.

И вам предлагаю его попробовать в своих программах и устройствах: Репозиторий и документация на английском.

Что есть в наличии:

Базовая реализация на Lua. Довольно полные реализации на Яве, Питоне и Си. Пока только отправка для Arduino и CodeSys ПЛК (тестировалось и работает на Овене, но должно пойти на чём угодно).

GUI инструмент для того, чтобы глядеть на происходящее и вмешиваться:

image

Программы для отправки и приёма данных на Питоне, Луа и Яве.

Они отрабатывают защиту от циклов, запрещая обратную трансляцию сообщения в течение 5 сек после прохода в прямом направлении. Коннекторы на Питоне для интеграции с обычным MQTT и напрямую с OpenHAB. Она проверяет, был ли уже апдейт данного топика в течение указанного времени, и если был, то пропускает новый апдейт только если данные изменились. Кроме того есть библиотека для ограничения потока повторных данных.

Я планирую постепенно переехать на этот протокол полностью, и вот один из примеров того, что я хочу получить с датчиками:

Они отправляют отсчёты через MQTT/UDP. Здесь три датчика в одной комнате (ну, или на улице, не принципиально). Получают эти отсчёты одновременно основная система умного дома (OpenHAB), база исторических данных и настенный монитор, который показывает температуру жителям.

И это при феерической простоте протокола. Вся прелесть MQTT/UDP в том, что в такой схеме отказ любого блока не создаёт никаких проблем всем остальным.

Сервер БД можно сдублировать вообще без проблем. Более того, в этой же схеме легко реализуются и избыточные схемы управления с дублированием. Например, слушая температуру выдают управляющее воздействие на батареи отопления. Хитрее будет сдублировать модули, которые занимаются управлением. На сегодня я планирую остановиться на сборе сигналов с датчиков и обмене между модулями умного дома. Но, наверное, это уже следующая история.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть