MQTT arOPC

[Айрат]

Добрый день.

Я знаю об этом, это небольшое искажение возникает именно при преобразовании числа в строку в интерфейсе OPC сервера. С самими данными всё в порядке.

Айрат

[Eugene1]

а исправить это можно/планируется ?

[Айрат]

Возможно чуть позже.
Задача ОРС сервера передать данные без искажений конечным получателям (ОРС клиент и MQTT), с этим всё в порядке. Интерфейс служит только для первичной диагностики.

Айрат.

[elperegrino]

Здравствуйте!
Возникла задача управлять имеющимися устройствами с MQTT именно через SCADA. Гугл предложил Ваш сервер. Есть несколько вопросов:
1) Я правильно понимаю процесс: для создания шлюза MQTT-OPC-SCADA нужно в arOPC создавать устройства, прописывать теги, привязывать их к топикам MQTT, затем уже в SCADA еще раз создавать такие же устройства и привязывать их к тегам теперь уже  вашего OPC сервера? Туповатое уточнение, но тем не менее: то есть нет режима "транслировать все" и разбираться уже на стороне SCADA.(процесс создания шлюза не описан в инструкции)
2) arOPC не умеет разматывать строки JSON в топиках? Или умеет? Где посмотреть? (в инструкции нет об этом вообще ничего)

[Айрат]

Здравствуйте!

1. Вы создаёте конфигурацию в OPC сервере, а SCADA просто получает список всех параметров из OPC сервера. В SCADA системе потом уже делаете привязку, OPC  тегов из OPC сервера, к внутренним переменным. Может какие то другие решения есть, но я с такими не сталкивался.

2. До этого руки не дошли ещё. Что представляет собой JSON строка? В вашем случае.

Айрат

[elperegrino]

1) Понял, буду экспериментировать.
Просто как идею на будущее (после осознания как работает SCADA уточню идею):  было бы здорово подписываться на общий топик устройства(подраздела устройства) и силами arOPC сервера вытаскивать из MQTT топика, теги (состояния и уставки)  парсингом JSON строки.
Так же,  по моему опыту, для тега лучше обеспечивать подписку на два топика: отдельно топик для установки параметра, отдельно на получение статуса, иначе, когда подписываешься на топик, в который сам же публикуешь, возникает "кольцо"(легко решается созданием двух тегов один на подписку, один на публикацию, вопрос удобства, и, извините, денег - лицензия на количество тегов). Сейчас к тегу можно прикрепить только один топик.
2) JSON как JSON: {"парамтр1":хх,"параметр2":yy,"параметр3":zz.qq,"параметр3":"строка",...}

[Айрат]

1. Парсинг, наверное, как универсальное решение сделать не получится. А ради одного случая, смысла нет.
В arOPC проблема кольцевания решена, можете смело работать с одним топиком. Ну, а так да, идея разделения топиков, для тега, хорошая, добавлю в Task list.
2. Понятно. Тут возникает ограничение, такой топик будет доступен только на чтение. По идее это и было причиной, из за которой не стал добавлять разбор.

Айрат

[elperegrino]

В общем: без JSON грустно: политика "один топик-одно значение" сильно отъедает и без того мелкой оперативной памяти устройств (бестолковые, незначащие названия топиков надо хранить, перебирать и обрабатывать, при хранении в EEPROM получаем тормоза при считывании) и после десятка значений-топиков сильно неудобно ковыряться с этими слешами, вложениями и пр., т.е для средних(от 10 значений) и крупных проектов мертворожденная идея.
Постепенно разбираюсь и для меня удивительно, почему почти ни у кого MQTT не внедрен в SCADA, понятно, что промыслам принципиально неинтересен этот потребительский "ширпотреб", но этож все-таки какой-никакой, а тоже рынок сбыта, так как главной проблемой большинства проектов является именно интерфейс пользователь-система.
Уговариваю:
Так это ж пока "один случай"(хотя, судя по ветке форума, уже два), вряд ли MQTT канет в лету в обозримом будущем(цена интерфейса к MQTT 1usd в розницу(ESP8266+esplink), цена modbus tcp -? ), а инструмента, позволяющего за адекватные деньги подключить "промышленный" интерфейс scada к ширпотребовской электронике и поделкам пионеров кроме Вашего пока нет. Ознакомьтесь с обсуждением какого-нибудь zeegbeetomqtt сообщества.

2)О JSON: такие топики со значениями только считываются такой длинной строкой с разнотиповыми значениями, запись можно делать и по одному значению,  в виде {"newstate":1}, в устройствах уже реализован обработчик JSON и ему безразлично со сколькими парами ключ-значение работать.
Прошу прощения за оффтоп.

[Айрат]

1. Не совсем пойму выгоду от использования JSON. Ну завели вы один топик, в который сбрасываете JSON пакеты. Логика от этого не поменялась. Вы всё равно оперируете парами {"параметр": значение}, а это значит всё равно где то надо хранить название параметра, для того, что бы определить, какие данные поступили в JSON пакете. Плюс нужен парсер JSON пакетов. Каким образом это обходится при использовании JSON?

2. Да, действительно, можно оперировать отдельными парами. В этом случае, конечно, придётся отбросить QOS и Retain функционал, либо он будет неполноценным. Но если это не критично, то почему бы и нет. Вы правы, надо будет это дело реализовать.

Я понимаю, работать со строкой и JSON пакетом удобно, наглядно, много готового ПО, опирающегося на это. Но почему то никто не вспоминает, что сам по себе MQTT протокол способен передавать данные в любом виде. Что бы передать к примеру число 4 294 967 295 не надо передавать 10 байт, в виде строки, достаточно 4 байт. А контроллеру потом не надо будет парсить JSON и преобразовывать строку в число. Да и в оперативе, не надо хранить название параметра, можно HASH сумму посчитать и по ней искать, всё одно будет быстрее чем разбор JSON пакета и приведение параметров к нужному типу.
Но, это уже не каждому пионеру под силу).

Айрат

[elperegrino]

1. не совсем так. Пытался сочинить пример с калькуляцией, короче чем на два экрана не выходит (стало любопытно, потом сделаю тестовый пример).
Тезисно: пример из проекта
Есть помимо прочего 5 вентиляторов (автоматизация сушильного шкафа сейчас работает в iot-MQTT panel в планшет, есть еще разная  автоматика, принято решение привести к общему знаменателю, ввести SCADA )
Для каждого вентилятора:   
публикуем: состояние, режим работы,  интервал включения, длительность включения, номер используемого датчика температуры, сигнал аварии (всего 7)
подписываемся: новое состояние, новый режим работы,  новый интервал включения, новая длительность включения, новый номер используемого датчика температуры (всего 6)
все значения параметров byte (меньше не бывает (битовая упаковка неоправдана))
при подходе "по топикам" длина топика постоянно нарастает, обработчики циклически работают с динамическими массивами (string) меняющейся длины, созданными не тобой (при 2 кб sram те еще грабли, память фрагментируется (массивы ведь должны хранится непрерывно) и программу часто срывает ).
при JSON мы один раз ищем есть ли "FANx" в названии топика, если да, то один раз парсим JSON раскидывая параметры в регистры.

Плюс данные из "приемника MQTT" спускаются по SLIP протоколу, а там число-это число, строка - это массив символов.

Магия с HASH (кстати, где посмотреть об этом способе, а то я слова по отдельности понимаю, а в смысл вместе они не складываются ))) )оправдана когда ты сам полностью в одном устройстве поднимаешь TCP-IP-MQTT стек , на имеющимся PHY (wi-fi, ethernet) и на нем же "шевелишь ногами"- тут как всегда, это или очень дорого или  очень сложно (читай объемно) или очень медленно. Выгоднее использовать отдельный контроллер, который будет заниматься только стеком TCP-IP-MQTT, а с основным будет общаться по SLIP.