MQTT
Что такое MQTT?
MQTT или Message Queue Telemetry Transport – это легкий открытый протокол обмена данными, работающий поверх TCP/IP, созданный для унификации обмена данных между устройствами M2M (Машинно-Машинное взаимодействие) и IIoT (Промышленный Интернет вещей).
Идеален для использования в контроллерах и датчиках где требуется небольшой размер кода и есть ограничения по пропускной способности канала.
Особенности протокола MQTT
Основные особенности протокола MQTT:
- Асинхронный протокол
- Компактные сообщения
- Работа в условиях нестабильной связи на линии передачи данных
- Поддержка нескольких уровней качества обслуживания (QoS)
- Легкая интеграция новых устройств
Протокол MQTT работает на прикладном уровне поверх TCP/IP и использует по умолчанию 1883 порт (8883 при подключении через SSL). Также, возможна работа через Winsocket
Обмен сообщениями в протоколе MQTT осуществляется между клиентом (client), который может быть издателем или подписчиком (publisher/subscriber) сообщений, и брокером (broker) сообщений (например, открытое ПО Mosquitto MQTT).
Издатель отправляет данные на MQTT брокер, указывая в сообщении определенную тему, топик (topic). Подписчики могут получать разные данные от множества издателей в зависимости от подписки на соответствующие топики.
Устройства MQTT используют определенные типы сообщений для взаимодействия с брокером, ниже представлены основные:
- Connect – установить соединение с брокером
- Disconnect – разорвать соединение с брокером
- Publish – опубликовать данные в топик на брокере
- Subscribe – подписаться на топик на брокере
- Unsubscribe – отписаться от топика
Топики представляют собой иерархическую структуру, похожую на путь в файловой системе. Например:
myhome/kitchen/temperature
myhome/kitchen/light
Все устройства, которые заинтересованы в получении обновлений информации по всему, например, что происходит на кухне, могут подписаться на топик myhome/kitchen/# (#-специальный символ, аналогичный "*" в файловых системах)
Датчик температуры публикует свои измерения в топик /myhome/kitchen/temperature
Выключатель - в топик /myhome/kitchen/light
Преимущества использования MQTT для устройств
- Является стандартом де-факто для современных облачных систем IoT (см обзор). Данный протокол поддерживается абсолютно всеми современными облачными и On Premises системами IoT
- Развитая экосистема opensource решений автоматизации и диспетчеризации, в том числе: HomeAssistant, OpenHab, Wiren Board, Node Red - (см. Обзор) - это позволяет оконечным устройствам легко использовать уже имеющееся ПО без необходимости разрабатывать Web- интерфейсы, мобильные приложения, Rule-engines и пр.
- ПО MQTT брокера, также, доступно в открытом исходном коде и портировано под основные ОС (https://mosquitto.org/)
- Поддержка данного протокола устройством позволяет использовать его совместно с большим кол-вом уже существующего ПО и легко интегрировать новые устройства
- Библиотеки для реализации клиентской части данного протокола, также, доступны в исходном коде и могут быть легко интегрированы в ваш проект
Недостатки и особенности реализации MQTT
Протокол хорошо специфицирует такие операции как подписка на информацию (топик) и публикацию информации в топик, но сам формат данных оставляет на усмотрение приложений IoT
Это привело к тому, что разные системы используют разные форматы данных и оказываются, на деле, несовместимы между собой
Например, популярные OpenSource системы управления УД: OpenHab, HomeAssistant и IOBroker поддерживают MQTT. Но при этом напрямую, не совместимы.
На мой взгляд, самая обширная и продуманная реализация MQTT из этих трех систем, у HomeAssistant. По крайней мере, она подразумевает разумную иерархию топиков. И поддерживает аж три формата взаимодействия, включая JSon. Также, описывает формат управления для типовых устройств Умного дома, таких как освещение, термостат и пр.
Отдельно стоит упомянуть MQTT Autodiscovery - механизм, при помощи которого HomeAssistant может одним кликом добавлять новые устройства, которые особым образом анонсируют себя на шине MQTT
Начиная с версии 2.4, OpenHab, также, анонсировал новый драйвер MQTT, в том числе, с поддержкой конвенции homie и AutoDiscovery
К сожалению, мои эксперименты с новым драйвером, проведенные некоторое время назад, показали, что он нестабилен. (если ситуация изменилась - обязательно отпишитесь в комментариях)
Старый драйвер стабилен, но достаточно примитивен. Подразумевает использование в качестве MQTT Payload простых команд: "ON", "OFF", цифровые значения датчиков, разделенные запятыми. Можно прикрутить JSon, но настройка этого крайне неудобна. Также, плоская как блин структура Item-ов OpenHab все еще крайне натянуто ложится на иерархическую структуру мира. Дальнейшие эксперименты я не проводил, так как постепенно перешел на HomeAssistant
IOBroker имеет более-менее продуманную структуру топиков, но вот беда, его авторам понадобилось зачем-то доработать сам брокер, отступив от стандарта.
Доработка заключается в том, что MQTT брокер, входящий в состав IOBroker-а не отправляет информацию обратно тому клиенту, который ее направил, даже если он в явном виде подписался на данный топик.
Сделано это, вероятно, для того, чтобы избежать закольцовывания сообщений между клиентом и брокером. Хотя разумная архитектура, а именно, разнесение командных топиков, через которые происходит управление устройствами, и статусных - это те, в которых устройства уведомляют брокер (и всех, кому это интересно) о смене своего состояния - решают данную проблему.
Можно спорить о том, полезная доработка или нет, но она уже привела к тому, что те устройства, которые делаются под IOBroker в принципе, не работают со стандарным Mosquitto, так как не заботятся о правильной архитектуре топиков, уповая на "костыль", внедренный в IOBroker. Любое отступление от стандартов - это всегда плохо.
MQTT в контроллере LightHub
В своем контроллере LightHub, я уже несколько раз усовершенствовал интерфейс, отвечающий за интерпретацию MQTT. Описание текущего интерфейса приведено здесь
Сейчас частично поддерживается конвенция homie, которая определяет рациональную и унифицированную иерархию MQTT топиков устройства, а также, публикует служебную информацию, при помощи которой, системы управления смогут автоматически настраиваться на те устройства, которыми управляет контроллер.
Также, контроллер может работать одновременно с системами OpenHab, HomeAssistant и IOBroker. Также, участники сообщества адаптировали контроллер под Domotics.
Данные особенности, тем не менее, не мешают использовать MQTT для межмашинного взаимодействия уже сегодня.
Конвертация форматов может производиться специально разработанным клиентом, подписывающимся на сообщения одного формата и публикующих их в другом формате в другие топики. У меня, например, ранее с такой конвертацией прекрасно справлялся NodeRed, не требуя ни строчки кода.
В статье использованы материалы из Wikipedia и IPC2u
1-wire
Технология достаточно старая и широко употребляемая
Изначально, выведена на рынок компанией Dallas - Все помнят таблетки для домофонов iButton- это оно
Устройство соединяется с контроллером по одному проводу (кроме общего) - отсюда название. Большое преимущество в том, что каждый чип имеет свой адрес, что позволяет термометры соединять просто параллельно
Я провел массу экспериментов с данным стандартом. Изначально, предполагая очень широко использовать его для управления Умным Домом
Спешу поделиться результатами:
Хуже всего, если для управления 1-wire шиной не использовать никаких специализированных контроллеров (подключение напрямую к PIN у Arduino устройств) - в этом случае, проблемы возникают уже при длине кабеля более 3-х метров
Для моих целей такое расстояние не подходило, поэтому я использовал I2C to 1-wire мост DS2482-100
Стоимость чипа на Aliexpress менее 100 руб, чип имеет аппаратный драйвер шины с режимом strong-pullup, что в разы увеличивает надежность работы системы.
Альтернативные решения, как правило, используют USB контроллеры шины 1-Wire на основе DS2490 но это подразумевает использование компьютера в составе контура управления. По опыту, надежность комплексного решения, включающего в себя PC, операционную систему, ПО, сетевую инфраструктуру, в любом случае ниже решения, локализованного в пределах одного контроллера. Поэтому ответственные задачи регулирования я реализовывал таким образом, что это регулирование происходит автономно, контроллером.
У себя я использую шлейф длиной около 150 м.
Термометры опрашиваются, относительно, устойчиво, что позволило предельно дешево и управляемо реализовать систему управления теплыми полами. Но сбои в считывании значений датчиков присутствуют. (В особенности, когда задействовано диммирование освещения или работает приточная вентиляция с фазовой регулировкой мощности нагревательного элемента)
Контроллер опрашивает датчики циклично, поэтому, единичные сбои не влияют на функционирование.
Если датчик не смог прочитаться 20 раз - нагревательный элемент отключается.
На практике, я рекомендовал бы, все же, не превышать длину шлейфа в 100м для более устойчивой работы.
Кроме термометров, я пробовал использовать самую разнообразную перефирию, вооружившись Datasheet - ами написав множество процедур для управления следующими чипами и устройствами на их базе:
DS2413
DS2408
DS2890
Если коротко - себя это не оправдало
Основная проблема - все же не очень хорошая помехозащищенность
Борьба с помехами в сети 1-Wire
Это, пожалуй, самое непростое в данной технологии. Описываю свой опыт:
- Шину 1-Wire прокладывайте на расстоянии от высоковольтных проводов, трансформаторов LED освещения и проводов LED освешения (провода дают сильную помеху за счет того, что сила тока велика и используется ШИМ модулирование)
- Не надо использовать экранированную витую пару. Я проложил STP 5-й категории, но при попытке заземлить экран - связь полностью теряется. Предполагаю, что это связано с увеличением емкости проводника.
- По отзывам, невитая пара (самый дешевый двужильный провод) дает лучший результат.
- Хороший опыт - подтягивать дальний конец провода через резистор 3-4 КОм к стабилизированному фильтрованному источнику питания 5Вольт.
- Отводы от шины в 2-3 метра, в целом, не ухудшают качества работы системы, но прилично упрощают монтаж.
Провод или без? Z-Wave или 1-wire, DMX, DALI, modbus, onOcean ?
Ответ на этот вопрос у каждого свой.
Как правило, если дом уже построен и отделка его завершена - ответ: без проводов.
К счастью, появились универсальные беспроводные технологии, такие как Z-Wave, которые позволяют создать внутри дома своеобразную "сеть" из устройств, которые взаимодействуют друг с другом используя радиоканал. При этом устройства могут ретранслировать друг другу полученную информацию, что позволяет охватить технологией довольно большие объекты.
В отличии от того же WiFi технология достаточно энергосберегающая. Если устройство не является контроллером или ретранслятором - оно может потреблять достаточно мало электроэнергии, что позволит ему очень длительное время питаться от батареи.
Стоимость устройств Z-Wave еще достаточно высока (стоимость ZWave чипа, входящего в состав каждого устройства, около $6).
Контроллеры, также, еще дороги, хотя появились относительно недорогие решения. Вот, например, контроллер на базе Raspberry PI
Интересующимся рекомендую посетить сайт z-wave.ru
Вот еще вариант - беспроводной стандарт enOcean. Инженерам удалось сделать невозможное: датчики (освещение,движение), выключатели, и даже термостаты батарей без элементов питания и проводов! Датчики движения и пульты подзаряжаются от фотоэлементов, термостат батареи отопления - от тепла батареи. Выключатели - от нажатия!
Прочитать можно тут: http://enocean.com.ru/
Цены посмотреть там же. Выключатель - 100 Евро, регулятор батареи - 280 Евро.
А вот пример беспроводного контроллера enOcean/ZigBee
http://dionabms.ru/products/smartstruxure-lite/wireless-gateways/mpm-un/
Увы, не бюджетно.
Что относительно WI-FI: WiFi устройствам, в целом, есть место в умном доме, но следует учитывать ограничения технологии: Энергоемкость, загруженность диапазона, зависимость от качества WiFi покрытия.
Например, WiFi розетка, чайник и диммер вполне имеют право на существование, так как имеют неограниченный доступ к электроэнергии.
В одной из статей я расскажу про собственную разработку: WiFi AC Dimmer, устройство, размещающееся в обычном подрозетнике, с ручкой для регулировки яркости освещения, которое, тем не менее, умеет по шине MQTT управлять другими устройствами (например, яркостью и цветом LED подсветки), а также, может управляться само по той же шине.
Вот нравится мне диммер, регулируемый вращающейся ручкой. Но ничего подобного интеллектуального я найти не смог. Пришлось сделать.
Также, на рынке имеется большой ассортимент устройств, взаимодействующих друг с другом по нестандартным радиопротоколам, как правило, в диапазоне 400 Мгц. Пример - устройства Noolight.
Мой вывод:
Если жилище только строится или проектируется, есть возможность подвести медь к ключевым местам. Это имеет смысл сделать
Во первых, это обеспечивает бесконечную автономность устройств. Без безумных затрат.
Ну а если к каждому устройству необходимо подвести питание - небольшая разница, будет это два провода или дешевый слаботочный кабель, содержащий 4 пары проводов.
Методом проб и ошибок я пришел к следующему подходу:
Провода от светильников, матов теплого пола и пр. стягиваются в несколько щитков. Туда-же провода от окрестных выключателей.
У меня получается один щиток на 50-70 квадратных метров. Обязательно надо подвести туда же кабель локальной сети, кабель термодатчиков.
На первых порах, провода могут быть просто временно скоммутированы по традиционной схеме, затем, в каждый щиток устанавливается Контроллер умного дома LightHub с нужным набором модулей (релейные, диммеры, LED и пр)
В своем доме я предпочитаю использовать именно проводное подключение узлов везде, где это возможно
DMX-512
Стандарт DMX-512 стар, стабилен и хорошо документирован
Протокол, прежде всего, ориентирован на управление до 512 устройствами, расположенными на одной шине. Каждое устройство имеет свой адрес
Вот примеры:
Хотя, как оказалось, тут тоже есть засада. Подробности ниже:
Для подключения всех LED светильников я заказал на AliExpress две такие вот платы:
Возможность управлять почти полутора киловаттами 24V лент с ограничением 2А на канал всего за 2,5 тыс руб подкупала. Причем, выходные ключи по даташиту тянут аж до 60 Ампер.
Но после подключения диммера к контроллеру он напрочь отказался понимать генерируемый им DMX512 сигнал.
При этом обе платы вели себя абсолютно идентично: в демо режиме функционировали абсолютно нормально. При помехах на входе, также, моргали каналами, а вот DMX сигнал ни с одного из двух имевшихся в наличии DMX Мастеров (панели на стену и собранного на Arduino) упорно не понимали.
Проблема оказалась в следующем:
Стандарт DMX не специфицирует интервал между передаваемыми каналами. То есть, Мастеру не возбраняется выдать в шину 3-4 канала, задуматься, затем следующие 3-4 канала и так далее.
Так, в частности, устроена популярная библиотека DMXSimple для Arduino
Как оказалось, контроллер не переваривал 2ms задержку между каналами (interframe delay). Несложная модификация кода библиотеки (сократил цикл в два раза) - и все работает
Вот так выглядит DMX сигнал после модификации библиотеки (цикл около 1 ms):
LED светильники и пульсация
Много написано про преимущества LED светильников. Поговорим о недостатках.
В отличии от ламп накаливания, светодиод, практически, не обладает инерционностью.
А значит это, что если светильник запитан от сети переменного тока, то если не принимать специальных мер, он будет малозаметно мерцать с удвоенной частотой сети, а именно, 100 раз в секунду.
На первый взгляд, это незаметно, но подобное освещение прилично утомляет.
Еще более заметна пульсация если использовать диммирование.
Для экспериментов я закупил на Aliexpress кучку вполне приличных с виду недорогих спотов. Вот таких.
Первое впечатление - вполне приятные светильники. Нейтрального белого (3000К) света
Заботливые Китайцы даже прислали на 10% больше спотов. Как я понял, на случай брака.
Диммируются.
После инсталляции, заподозрив неладное, я посмотрел на светильники через камеру смартфона
На фото изображение в контрастную полоску. Что свидетельствует о серьезном уровне пульсации.
Для разбирательства с вопросом был собран вот такой стенд:
Последовательно со светильником был подключен резистор номиналом 8 Ом и при помощи осциллографа было зафиксировано падение напряжение на этом резисторе. Соответственно, далее приведены диаграммы тока через светодиоды.
(Внимание, если будете повторять эксперимент НЕ заземляйте осциллограф. У меня нет уверенности в том, что китайский драйвер светодиодов дает гарантированную гальваническую развязку от сети. Есть хорошая вероятность уничтожить дорогой прибор)
вот так выглядит диаграмма тока при максимальном уровне диммирования.
а вот так в случае "приглушенного" света
Комментарии излишни
Драйвер светодиодов абсолютно не занимается стабилизацией тока, проходящего через светодиоды. Отсюда гигантский уровень пульсации.
Ну что же. Поставим на выход драйвера конденсатор емкостью 1000 мФ
Это максимум диммера
А это ближе к минимуму
Намного лучше, не правда ли?
Камера смартфона такой уровень пульсации, фактически, не замечает.
Update спустя пару лет:
За это время, из 40 драйверов светильников 10 штук постепенно но с грохотом взорвались )
В основном, выходит из строя высоковольтный конденсатор.
Драйвера по мере "взрывания" меняю на приличные эквиваленты.
Сами споты надежнее - вышло из строя всего пара штук. В целом эксперимент надо признать не очень удачным. К выбору спотов надо подходить ответственнее.
Страница 1 из 2