Ориентировочные сроки?
Не давлю, просто раскидываю свои приоритеты: иногда легче дописать десяток строк самому, чем ждать.
Поглядел. Дофигища переделывать придется под v5…
Как вариант, делать сообщения комплексными. Самое простое JSON:
{value: 53, timestamp: 1632505816.837037, flags: [SB,IV]}
Правда, трафик увеличит, но зато каждое полученное значение чётко связано со временем.
1 лайк
Ну да, мне и мету подоткнуть нетрудно, посредством wb-rules (особенно когда сей демон работает и не падает), и поймать на скаде.
С другой стороны, opc/ua, хоть и тяжеловесен весьма, есть таки industry standard и моститься им со «взрослыми» устройствами гораздо правильнее.
Думаю пока.
opc/ua - это-ж COM/DCOM, т.е. Windows.
а /meta не подходит. Это ещё одна публикация
потеряется связь значения и мета-информации…
Ви таки не поверите, несчастных полгода назад я ошибался так же. Потом почитал, покурил, посыпал пеплом свои буйные кудри и уже написал драйвер этого протокола под свою скаду.
Как именно? Если предположить, что пакет с этим топиком и подтопиком вылетит синхронно, то синхронно он и прилетит? Нет, я понимаю, что синхронность в mqtt понятие условное, но не переставляются же значения местами в очереди?
А если mqtt-сервер выдаст сначала все сообщения одно топика, затем другого?
Для точной связки данные-метаданные обязательно должен быть один пакет и его получение, как и отправка, должны быть атомарными процессами.
Да согласен я, конечно: решение нечистое. Просто если заворачивать переменную в «метапакет», придется остальные компоненты ВБ-софта переучивать на вылущивание ее оттуда, проще уж целиком v5 ввести.
Ну, хм, либо дублировать топик в таком виде только для скады, что не добавляет совместимости, можно с равным успехом свой протокол выдумывать…
…или разок крепко поднатужиться и нормально сделать вокруг opc/ua, благо шлюз у ВБ уже есть. Надо его понюхать и вынести вердикт.
Если v5 вводить, то не только “остальные компоненты ВБ-софта переучивать”, но и весь сторонний софт.
А кто у нас сторонний софт?
Скаде в общем все равно на версию протокола, v5 сто лет как стандарт. Ведомым контроллерам достанется апдейт на ту же версию, что стоит на ведущем. Лепота!..
…только б дожить. Что-то у ребят неимоверно, чудовищно медленно тянутся дела с ПО.
Хороший аргумент против opc/ua именно с ВБ - это [мои текущие] непонятки на тему буферизации сообщений. Если москита при падении связи держит (ну должен держать) в очереди столько топиков, сколько сможет, то упоминаний на эту же тему в листочке на opc/ua шлюз я с разбегу не нашел.
Если буферизации нет, то для моих целей неприемлемо, надо также доделывать.
MQTT v5 брокер совместим же с v3-клиентами. Просто таймстампа в сообщениях не будет и всё.
Кстати про OPC UA:
Эт я помню. Просто еще не дергал на тему буферизации данных (HDA). У москиты есть очередь, а с v5 [когда-нибудь] появятся и метки времени.
Это тоже надо проверить, есть мнения, что нет. Но мне вангуются многочисленные блуждающие глюки в случае, если v5 ядро прислюнявливать к текущим версиям остальных демонов. Лучше бы переворошить сразу всё: труднее, но надежней.
работает конечно. Сам v5-брокер (mosquitto 2.x) заедет уже в текущем тестинге
Наконец-то, отлично!
Больше не будет необходимости в сборках с вашими патчами и mosquitto можно будет обновлять прямо из их репозитория http://repo.mosquitto.org/debian/?
С этого места подробнее можно? Похоже, я убил 3-4 дня впустую.
патчей не будет, но использовать мы всё-таки хотим родные debian-овские репозитории.
1 лайк