Вчера к нам на коллективку приезжали друзья из за рубежа «Василий 1 Николай Елена» и «Женя 0 Дима Костя Анна», к сожалению сегодня уехали, но остался «Сергей Павел 1 Радио Тамара»
Достаточно Connect/ConnAck, Will опциональная фаза. И предназначена только для того, чтобы те, кому это интересно, узнал о потере связи с нодой. Что порой бывает полезно.
И кстати, в самом MQTT фазу Connect опустить не возможно. И адрес гейта надо просто знать, если гейт упал, упс. Представьте как весело в сети с DHCP.
А в MQTT-SN можно, QOS — 1 в помощь.
Выглядит следующим образом:
1. Нода с пустой прошивкой шлет: Search Gateway.
2. Гейт отвечает: GWInfo
Если адрес гейта нам известен первые 2 пункта можно опустить.
3. Нода шлет Publish QOS-1, ответ на сообшение не требуется.
Обмен с CONNECT'ом
1. N. SearchGW
2 G. GwInfo
3. N. Connect, w/o will
4 G. Connack
4 N. Publish with QOS 1
5 G. PubAck
Если ноде что то надо от сервера, т.е. если сервер должен посылать ноде какие либо данные.
6. N. Subscribe *
7. G. SubAck
Всё, мы взяли ноду с пустой прошивкой, она САМА нашла к кому подключаться. И у нас уже работает двухсторонний обмен.
Собственно мы пилили сперва свой протокол, потом наткнулись на MQTT-S тогда ещё.
Оказалось что мы практически скоммуниздили один в один, и для совместимости обошлось практически только правкой дефайнов.
А кто подскажет вариант с низкой задержкой,
Данная сборка у меня давала задержку относительно камеры до 10 секунд.
Идеально было бы с задержкой менее секунды opensource под linux.
Проще задавать произвольный путь. Возможные уровни:
здание/этаж/помещение/узел/(сенсор или актор)/параметр
у наc используется /dev/узел/(сенсор или актор) — и этого уже нехватает.
При разработке схожей системы столкнулся со следующими сложностями:
— при наличии большого количества модулей, хранить все переменные/сигналы в голове уже сложно. Необходимо место где это можно посмотреть, желательно с организацией в виде дерева.
— из-за лимитированных ресурсов ограниченны возможности отладки, разработку алгоритмов упрощает использование FBD подобного языка.
— для отладки желательна возможность послать произвольные сигналы и смотреть текущее состояние переменных.
Интересно, у них что разогнали и набрали по новой отдел разработки? Что то слишком много изменений за раз.
НАКОНЕЦ-ТО избавились от глючного моста USB-UART на ATMEGAxUx и поставили нормальный отладчик.
Не забыли ESD защиту на USB.
Разъёмам JTAG/SWD никто не мешает, можно подключиться более «взрослым» отладчиком.
Передвинули диод защиты от переполюсовки с параллельного включения на последовательное.
Единственное что импульсный стабилизатор остался тот-же, а это значит внешнее питание 7-12V, что несколько ограничивает области применения.
Ну а так по сравнению с DUE очень серьёзный шаг вперед.
У меня на нем работает сервер домашней автоматизации, по отзывчивости где то на уровне Intel Atom'a N330, но потребляет существенно меньше. Загрузка процессора не отслеживается(ниже 1%), памяти жрет не больше 80 мегабайт.
По сравнению с Малиной работает ощутимо быстрее, но опять-же, всё чисто субьективно.
Пы.сы, «Whísky 1 Novémber Écho» -> W1NE, «Víctor 0 Délta Kílo Álfa» — > V0DKA, «Siérra Papá 1 Rómeo Tángo» -> SP1RT, нормальные позывные.
73, ex UN7LAG
И кстати, в самом MQTT фазу Connect опустить не возможно. И адрес гейта надо просто знать, если гейт упал, упс. Представьте как весело в сети с DHCP.
А в MQTT-SN можно, QOS — 1 в помощь.
Выглядит следующим образом:
1. Нода с пустой прошивкой шлет: Search Gateway.
2. Гейт отвечает: GWInfo
Если адрес гейта нам известен первые 2 пункта можно опустить.
3. Нода шлет Publish QOS-1, ответ на сообшение не требуется.
Обмен с CONNECT'ом
1. N. SearchGW
2 G. GwInfo
3. N. Connect, w/o will
4 G. Connack
4 N. Publish with QOS 1
5 G. PubAck
Если ноде что то надо от сервера, т.е. если сервер должен посылать ноде какие либо данные.
6. N. Subscribe *
7. G. SubAck
Всё, мы взяли ноду с пустой прошивкой, она САМА нашла к кому подключаться. И у нас уже работает двухсторонний обмен.
Собственно мы пилили сперва свой протокол, потом наткнулись на MQTT-S тогда ещё.
Оказалось что мы практически скоммуниздили один в один, и для совместимости обошлось практически только правкой дефайнов.
Как сoбственно мы и сделали в своём проекте Enviriot
Есть устройства ethernet/rs485/rf, сервер работающий под виндой либо линуксом.
На случай полного отказа центральной системы был прикручен маленький PLC в сами устройства. На сервере есть «большой» PLC с FBD либо JavaScript.
Гарантия доставки пакетов это часть протокола для QOS 1/2.
Даже по RF на 868/443MHz всё работает достойно.
Дублирование сервера то-же часть протокола. Устройства автоматически находят активный гейт/брокер.
А модификация протокола который изначально построен по принципу устройство — определенный гейт — это сова на глобусе.
Данная сборка у меня давала задержку относительно камеры до 10 секунд.
Идеально было бы с задержкой менее секунды opensource под linux.
Не требует установленный Офис, opensource & «totally free to use». Есть множество примеров.
здание/этаж/помещение/узел/(сенсор или актор)/параметр
у наc используется /dev/узел/(сенсор или актор) — и этого уже нехватает.
— при наличии большого количества модулей, хранить все переменные/сигналы в голове уже сложно. Необходимо место где это можно посмотреть, желательно с организацией в виде дерева.
— из-за лимитированных ресурсов ограниченны возможности отладки, разработку алгоритмов упрощает использование FBD подобного языка.
— для отладки желательна возможность послать произвольные сигналы и смотреть текущее состояние переменных.
Проект класный, буду следить за развитием.
НАКОНЕЦ-ТО избавились от глючного моста USB-UART на ATMEGAxUx и поставили нормальный отладчик.
Не забыли ESD защиту на USB.
Разъёмам JTAG/SWD никто не мешает, можно подключиться более «взрослым» отладчиком.
Передвинули диод защиты от переполюсовки с параллельного включения на последовательное.
Единственное что импульсный стабилизатор остался тот-же, а это значит внешнее питание 7-12V, что несколько ограничивает области применения.
Ну а так по сравнению с DUE очень серьёзный шаг вперед.
У меня на нем работает сервер домашней автоматизации, по отзывчивости где то на уровне Intel Atom'a N330, но потребляет существенно меньше. Загрузка процессора не отслеживается(ниже 1%), памяти жрет не больше 80 мегабайт.
По сравнению с Малиной работает ощутимо быстрее, но опять-же, всё чисто субьективно.