Привет.
Главным недостатком mqtt как протокола управления, несомненно, является асинхронность: в условиях распределенной сети время путешествия телеграммы не определено. Если все устройства собраны вокруг одного контроллера, ответ за своевременную реакцию периферии лежит только на его начинке.
А если мы имеем несколько устройств на сети общего пользования, особенно в условиях почти наставшего чебурнета, всё становится принципиально печальней. Контроллер за время отсутствия связи накопил сообщений об изменении какого-то параметра, потом выплюнул их все за несколько миллисекунд - и поди пойми, ВО СКОЛЬКО в подвале открылась и закрылась дверь. Или выключили воду. Итд.
Видится два варианта осмысленного обмена данными.
Первый - двигаться в сторону opc/ua как связующего протокола между узлами и/или серверами. Индустриальный стандарт, документированный, строгий, совместимый со всеми.
Второй - продолжать юзать простой и легкий mqtt, добавив в демоны один подтопик - реальное время опроса датчика. Который подтопик вкупе с qos снимет любую неопределенность, кроме собственно времени путешествия телеграммы, но и существенность последнего снизит до пренебрежимой в большинстве применений.
мы планируем это добавить в MQTT. В MQTT 5 подвезли пользовательские аттрибуты сообщений и мы планируем добавить таймстамп с помощью этого самого аттрибута.
Я думаю в топиках нужно передавать не только значение и метку времени, но и код качества, который содержит биты обозначающие признаки сигнала из МЭК 60870-5-101 7.2.6.3 Описатель качества (отдельный байт)
А в нем уже отражать работает датчик или нет, устанавливая соответствующие биты: SB = проведено замещение/нет замещения - когда установили из скрипта или веб интерфейса. NT = неактуальное/актуальное значение - когда датчик длительное время выдает одинаковое значение чего в реальности не бывает. IV = недействительное/действительное значение - тут все просто - когда нет связи с устройством (по Modbus например)
Протокол МЭК 60870-5-101 уже достаточно устарел, а документацию на IEC 62541 (OPC UA) в бесплатном виде в интернете сложно найти, но думаю там есть что-то подобное.
Думаю домашняя автоматизация ближе к автоматизациям диспетчерского технологического управления в электроэнергетике, чем к автоматизациям на производстве где требования к скорости работы выше.
Из Wirenboard - не получится полноценный аналог контроллеров конвеера, а вот аналог контроллеров телемеханики легко.
Ви таки не поверите, несчастных полгода назад я ошибался так же. Потом почитал, покурил, посыпал пеплом свои буйные кудри и уже написал драйвер этого протокола под свою скаду.
Как именно? Если предположить, что пакет с этим топиком и подтопиком вылетит синхронно, то синхронно он и прилетит? Нет, я понимаю, что синхронность в mqtt понятие условное, но не переставляются же значения местами в очереди?
А если mqtt-сервер выдаст сначала все сообщения одно топика, затем другого?
Для точной связки данные-метаданные обязательно должен быть один пакет и его получение, как и отправка, должны быть атомарными процессами.
Да согласен я, конечно: решение нечистое. Просто если заворачивать переменную в «метапакет», придется остальные компоненты ВБ-софта переучивать на вылущивание ее оттуда, проще уж целиком v5 ввести.
Ну, хм, либо дублировать топик в таком виде только для скады, что не добавляет совместимости, можно с равным успехом свой протокол выдумывать…
…или разок крепко поднатужиться и нормально сделать вокруг opc/ua, благо шлюз у ВБ уже есть. Надо его понюхать и вынести вердикт.
А кто у нас сторонний софт?
Скаде в общем все равно на версию протокола, v5 сто лет как стандарт. Ведомым контроллерам достанется апдейт на ту же версию, что стоит на ведущем. Лепота!..
…только б дожить. Что-то у ребят неимоверно, чудовищно медленно тянутся дела с ПО.
Хороший аргумент против opc/ua именно с ВБ - это [мои текущие] непонятки на тему буферизации сообщений. Если москита при падении связи держит (ну должен держать) в очереди столько топиков, сколько сможет, то упоминаний на эту же тему в листочке на opc/ua шлюз я с разбегу не нашел.
Если буферизации нет, то для моих целей неприемлемо, надо также доделывать.
Это тоже надо проверить, есть мнения, что нет. Но мне вангуются многочисленные блуждающие глюки в случае, если v5 ядро прислюнявливать к текущим версиям остальных демонов. Лучше бы переворошить сразу всё: труднее, но надежней.
Наконец-то, отлично!
Больше не будет необходимости в сборках с вашими патчами и mosquitto можно будет обновлять прямо из их репозитория http://repo.mosquitto.org/debian/?
