Просмотр полной версии : ПР200+ NB114 Edyte gateway MQTT
Добрый день,
Есть необходимость считывать и изменять данные на ПР200 через MQTT client, для этого используется NB114 Edyte Gateway который поддерживает MQTT протокол, NB114 подключил к брокеру, Mqtt Client Android тоже поключен, осталось не ясным как правильно писать mqtt сообщения для того что бы считывать и изменять сетевые переменый на пр200, и как провавильно настроить modbus
С последнего и надо было бы начинать. Без дополнительного контроллера (конвертера) не обойтись.
Я не увидел возможности преобразования из(в) Modbus в(из) MQTT, преобразование Modbus TCP - RTU вроде указано.
Где вы увидели первую возможность? дайте ссылку на документацию данного шлюза и где написано про первый вариант ?
з.ы. с подобной задачей точно справится RapidScada с установкой на OrangePi и подобное + модуль автоуправления от разработчика
Еще возможно IntraSCADA, у них оба протокола присутсвуют +скрипты для перенаправления или возможно просто настройками\
Serebrum скорее всего справится, но у них был шифрованный MQTT но скорее всего можно использовать и открытый.
Наверняка ряд других....
Покажите на каких страницах искать настройки Modbus в(из) MQTT а то много текста там...
Добрый день,
Есть необходимость считывать и изменять данные на ПР200 через MQTT client, для этого используется NB114 Edyte Gateway который поддерживает MQTT протокол, NB114 подключил к брокеру, Mqtt Client Android тоже поключен, осталось не ясным как правильно писать mqtt сообщения для того что бы считывать и изменять сетевые переменый на пр200, и как провавильно настроить modbus
Надо уметь писать Modbus-запросы в двоичном виде. Похоже это устройство передает содержимое топиков как есть. Ну и соответственно уметь читать ответы. Здесь обычный MQTT-клиент не подойдёт. Нужен такой, который может формировать Modbus- запросы и отправлять на MQTT-сервер сразу. Полученный Modbus-ответ также разбирать самостоятельно.
Или приложение MQTT Dash, которое позволяет на JavaScript писать обработчики событий. Если сможете реализовать функции формирования rtu запросов и разбора ответов, то должно получиться.
Не увидел даже намека на то, что оно может в(из) разных в принципе протоколов что-то передать...
имхо, варианты программных шлюзов набросал выше. с RapidScada проверенный, правда делали обмен между ПР200 и кондиционером Kentatsu. Но суть не меняет, между разными протоколами можно настроить шлюз. Потребуется платный Модуль Автоуправления от разработчика Scada.
Второй вариант с IntraScada просто потому, что они поддерживают Modbus и MQTT, и вроде как там есть скрипты, то есть вариант шлюзования тоже есть, только как настраивать не знаю. Можно в личку разработчикам написать.
Третий только предположение, так как Серебрум в принципе умеет и Modbus и MQTT...
Поддержка разработчика очень вялая , отвечают раз в 5 дней и не какой конкретики, типо с смотри и читай мануал а там информация очень размытая.
Видимо потому, что фактически это прозрачный шлюз с возможностью преобразования Modbus RTU в TCP и обратно. И для чего то имеющее подключение по MQTT к различным облакам...
Да, так и есть , необходимо посылать команду через mqtt клиента в хец формате, но не все клиенты особенно мобильные дают это делать.
Я подключал такие шлюзы через бесплатные публичные MQTT-сервера к приложениям на Android.
Идея очень проста:
На 21 стр. в самом верху даны образцы настроек формы для прибора и формы для клиента.
Используется всего 2 топика: Subscribe-топик и Publish-топик, пусть мы дадим им имена "Request" и "Response".
Соответственно, прибор при включении подписывается на "Request".
Когда клиент положит в него массив байт с запросом, то MQTT-сервер тут же перешлет его на прибор через этот топик.
Прибор извлекает его из MQTT-пакета как есть и транслирует в сеть RS-485.
Получив ответ из сети, он публикует его в топике "Response".
Соответственно, клиентское приложение при подключении к MQTT, наоборот, подписывается на "Response" и получает ответ сразу же как прибор его опубликует на MQTT-сервере.
Такой способ обмена я использую при работе с модулем SIM800L (который, кстати, впаян в ПМ01).
Он использует только GPRS соединение с Интернетом и не требует статических IP (VPN и т.д.)
причем есть ограничение на длину, 40 символов ASCII и 20 символов HEX - страницы 21-22. В общем особо каши не сваришь...
Проблема в том, кто будет преобразовывать стандартный запрос например Modbus RTU в строку топика и преобразовывать потом обратно из строки ответа в ответ от Modbus устройства ? Видимо Вася Форточкин :)
Это для Heartbeat Packet.
Написано: This heartbeat packet is not MQTT heartbeat and need to be turned of in MQTT client mode.
В описании MQTT-протокола сказано, что можно за раз передать массив размером 268 435 455 байт.
Кстати, в моем случае передавались/принимались ОВЕН-запросы/ответы (шлюз работал с ОВЕН-сетью).
В моем случае само Android приложение формировало стандартный ОВЕН-запрос и заворачивало его в MQTT-пакет и обратно.
Проблема была в другом - полное время прохождения пакета через всю цепочку (особенно по сотовым сетям).
Среднее время ответа было около 0.8 секунды, но периодически приходилось ждать до 5 сек.
Так а в случае с Modbus разве не получается Heartbeat Packet ?
MQTT символьный протокол, Modbus скорее бинарный. Овен вроде тоже символьный.
Да, так и есть , необходимо посылать команду через mqtt клиента в хец формате, но не все клиенты особенно мобильные дают это делать.
Это верно! Придется изучать MQTT Dash и встроенный в него JavaScript. Надеюсь параметров не очень много?
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot