Настройка процесса отправки сообщений по MQTT-мосту


#1

Добрый день!

Возник следующий вопрос. Можно ли каким-либо способом регламентировать процесс отправки сообщений удаленному MQTT-брокеру? В частности производить их отправку только в том случае, когда значение изменилось (отлично от предыдущего) или через заданный промежуток времени. Чтобы сообщения не сыпались валом. Я прочитал несколько веток на форуме, но к сожалению не сложил для себя пока ясной картины. Видимо сказывается отсутствие некоторого опыта и знаний. Буду рад, если разъясните и подскажите направление поиска/действия.


#2

Добрый день!
Для прямого ответа на ваш вопрос нужно смотреть документацию по настройке MQTT-моста в брокере. Можете погуглить по запросу “mosquitto bridge settings”. Я ничего подобного не делал, всегда настраивал мост только с трансляцией всех сообщений.
Если сообщения у вас появляются про опросе устройств RS-485 нашим стандартным драйвером, то можете настроить частоту опроса устройств в нём.


#3

ещё обратите внимание, что большинство наших драйверов и так отправляют сообщения в MQTT только если значения поменялись


#4

Если нужно передавать не все значения, то можно просто создать отдельный топик для бриджа, и туда перезаписывать нужные значения по таймеру или по нужному событию. Мы делаем так.


#5

Коллеги, благодарю за ответы.

Уважаемый Demix, я думал про такой вариант, но пока нет достаточного багажа знаний, чтобы реализовать. Я так понимаю это можно сделать с помощью правила. Не сочтите за наглость, можно ли попросить небольшой пример? Если не затруднит.


#6

Создаем виртуальные устройства, для всех параметров, которые нам нужно передавать через бридж.

Пример для двух показаний, можно размножить до нужного Вам количества:

defineVirtualDevice("Sensors", {
	title : "Датчики",
	cells : {
		T1 : {
			type : "text",
			value : 0
		},
		T2 : {
			type : "text",
			value : 0
		}
	}
});

В настройках бриджа подписываемся на этот топик Sensors со всеми подтопиками:

topic /# out 1 /devices/Sensors/controls /topik_on_server

И теперь просто пишем необходимое правило, по которому нужно собирать и отправлять показания.
Для этого, в теле функции, в созданные нами виртуальные устройства записываем необходимые показания:

dev[“Sensors”][“T1”] = тут путь к нужному показателю.

Например правило, которое отправляет раз в час состояние выходов А1 и А2:

defineRule(“sendDataToServer”, {
when: cron("@every 1h00m"),
then: function () {
dev[“Sensors”][“T1”] = dev[“wb-gpio”][“A1_OUT”] ;
dev[“Sensors”][“T2”] = dev[“wb-gpio”][“A2_OUT”] ;
}
});

Правило можно написать и по таймеру, и по сработке определённых датчиков. Если что-то не понятно, то спрашивайте.


Нестандартные топики
#7

Demix,

Благодарю Вас за ответ. Как рас разбираюсь во всех тонкостях. Если будут вопросы обязательно напишу.


#8

Евгений,

Согласен. Но что делать со значениями, которые колеблятся во втором/третьем знаке после запятой и эти колебания просто неважны и отправлять их брокеру нет необходимости? Или ситуация, когда значение колеблется в малой окрестности допустимого значения и этим колебанием хочется пренебречь. Исключить, так сказать, “шумы”. Смысл спамить облако?

Создавать кучу виртуальных устройств, которые будут функционировать с этой точки корректно тоже не выглядит хорошим решением. Есть ли все-таки способ централизовать процесс? Капнуть глубже виртуальных устройств и скриптов-правил.


#9

Благодарю еще раз. Ваша подсказка помогла. Разобрался со скриптами-правилами, научился делать свои интерактивные элементы управления и в реальном времени управлять процессом отправки данных брокеру (по таймеру в заданное время, через заданный промежуток времени, по выходу из диапазона допустимых значений и т.п.). Но… теперь куча виртуальных устройств и объемные скрипты. Так и не найду никак ответ на вопрос… Можно ли изначально прописать правила обработки показаний, так сказать, на низком уровне…?


#10

Интересует не конкретно RS-485, а отправка сообщений в целом. Моя задача исключить “шумы” при отправке сообщений. В случае если величина изменилась незначительно с прошлого раза ее не нужно отправлять вовсе. Смысл? Засорять канал и отправлять брокеру излишние данные. Куда эффективнее контролировать и регламентировать процесс. Особенно, если речь идет об интеграции с облачным сервисом, например.

Совет с гуглением конечно дельный, но, поймите правильно, лучше разработчиков контроллер не знает никто. Поэтому и обратился к Вам, коллеги… Что касается драйвера, то нельзя ли подробнее. Какие варианты еще могут быть. Спасибо.


#11

Теоретически это можно сделать в виде, например, отдельного модуля, который бы организовывал mqtt-бридж. Практически сейчас этого нет и в очереди разработки вряд ли появится в ближайшее время.

Сделать можно на любимом, желательно быстром, языке программирования: C, C++, Go. Физически mqtt-бридж отличается от обычного подключения клиента только одним битом в заголовке, поэтому кода там будет строчек 200 от силы.


#12

Евгений, благодарю за ответ. Согласен, но вот в чем загвоздка. Желания у меня хоть отбавляй, а вто знаний пока не так много. Я учусь и разбираюсь. Но некоторые вещи для меня пока не так очевидны. Опыт программирования имеется. Тут без вопросов. Подскажите с чего можно начать разработку такого модуля. Что взять в качестве примера, если таковой имеется. Спасибо.


#13

я собственно написал всё, что нужно, если опыт программирования у вас имеется. Выбирайте язык программирования, выбирайте библиотеку для MQTT для него, дальше делайте два клиента, одним подключайтесь к удалённому брокеру, другим - к локальному.


#14

Благодарю, Евгений. Буду пробовать.


Яндекс.Метрика