Добрый день!
Я отчасти разделяю ваши чувства.
Но, переходя к сути, вижу за ними только одну реальную проблему (настройки бриджа в mosquitto не работают с топиками с пробелами, потому что так захотели разработчики mosquitto) с простым обходным решением (создать свои копии шаблонов без пробелов).
Сталкивались ли вы ещё с какими-то проблемами из-за пробелов?
а у меня была проблема с VOC топиком , из-за круглых скобок не работает в OpenHab
Решается проблема у меня таким способом:
Присоединяюсь ко всем негодующим, может хотя бы в следующих девайсах не будете использовать спецсимволы в топиках.
1 лайк
Уже пробовал - не помогло
Даже с небольшим количеством модулей через бридж по умолчанию “летит” большое количество данных.
Траффика за месяц набегает более 1,5 Gb
Лишние деньги за превышение приходится отдавать и забивается БД на сервере.
Отладить приложение не просто, когда валит чухом состояние всего, что, как я понимаю, и предлагается делать, если забить на пробелы и, тем самым, бриджем не заниматься.
Ну и очень интересно все-таки узнать причины такого положения дел. Что побудило разработчиков таким образом поименовать топики.
Или так, раз уж mosquitto такой кастомный и ну никак не работает с пробелами, может есть предложение, какой еще брокер можно использовать, который так же пользуется спросом, но не имеет этих ограничений? Ну чтоб он был распространен и т.д.
Мне показалось, что вы, разработчики, упоминаете mosquitto, вероятно, пользуетесь. А такой ляп не торопитесь исправлять… Возможно, причины в другом? Может глючить начинает контроллер, если много записей будет в бридже, может еще какие косяки, и потому вы и не наводите в этом вопросе порядок.
А мне это очень странно. Программисты использовали архитектурно в названия переменных пробелы (спецсимволы)?!. Интернет, как бы, однозначно говорит, - да, спецификация позволяет, но не делайте этого, пожалуйста, никогда! Иначе замучаетесь потом глюки ловить.
Я логику не понимаю. Одно с пробелом, другое - с подчеркиванием.
Главное, ведь, - конечный пользователь никогда не увидит этих названий. Ему все равно, что там написано в топиках, он увидит “Свет в гостиной”. Только инсталлятор их видит, а ему эти пробелы (скобки, …) - “очень мешают”. И даже инсталлятор в большинстве случаев не пишет эти жуткие названия, он их копипастит из интерфейса.
Ну то есть ни одного плюса в названии “External Sensor 1” лично я не вижу, - одни минусы. А ответ разработчика - “это не работает, потому что так захотели разработчики mosquitto”.
Причем здесь разработчики mosquitto? Они пробелы и скобки в названиях переменных в шаблонах wirenboard использовали? Их косяк (такое поведение бриджа “супротив спецификации”) - это их косяк. Так косяков разных много, поэтому разумный интернет и пишет в white paper, чтобы не нарываться на чужие грабли, и обходить даже будущие возможные ошибки, - “никогда не используйте пробелы и спецсимволы в названиях переменных”.
3 лайка
и вот этот разброд в логике очень напрягает) Сразу понимаешь, что где-то еще будут недоделки и косяки( И такое знакомое чувство ожидания подвоха на каждом шагу)
Также столкнулись с проблемой наличия пробелов в названиях mqtt топиков при настройке бриджа. Сейчас планируем править шаблоны всех устройств с которых надо пересылать некоторые метрики через бридж в облако. В связи с этим вопросы:
- Как правильнее делать - создавать новые пользовательские шаблоны в /etc/wb-mqtt-serial.conf.d/templates или править стандартные шаблоны в /usr/share/wb-mqtt-serial/templates ?
- Шаблоны довольно большие. Для того, чтобы убрать пробелы в названиях mqtt топиков, какие секции в шаблоне надо править (groups, parameters, channels, translations)?
Попробуйте передать конкретно топик, в имени которого есть пробел, и поймете. Например, такой настройкой:
topic /Ch 1 Total P out 2 /devices/wb-map12e_180/controls /AIG2NB6T/wb-map12e_180
Нам нужно передавать для обработки в облако конкретные топики от конкретных устройств, если передавать все (например, так topic /# out 2 /devices/wb-map12e_180/controls /AIG2NB6T/wb-map12e_180) это бессмысленно расходует ресурсы.
Ага, понятно, попробовал. Ищью так и висят уже годами.
Я бы сделал просто перепубликацию нужных топиков в некий подтопик типа /export
Это точно проще.
Но вообще - лучше конечно в пользовательские.
channels
Я бы сделал просто перепубликацию нужных топиков в некий подтопик типа /export
Это точно проще.
А можно этот вариант поподробнее?
Функцию, которая создает правила. На вход функции подавать топики - и в общем все. Правило перепубликовывает (только топик!).
//02_23_test_01.js
function mqtt_republic(sTopic, dPath){
defineRule("republic_"+sTopic, {
whenChanged: sTopic,
then: function (newValue, devName, cellName) {
publish(dPath+devName+"/"+cellName, newValue, 2, false);
//log.info(dPath+devName+"/"+cellName)
}
});
}
mqtt_republic("hwmon/CPU Temperature", "/testpath/");
mqtt_republic("wb-adc/Vin", "/testpath/");
Насколько я понял, в чистом виде этот скрипт не решает проблему пробелов в имени топика. Его надо модифицировать, чтобы он менял наименование топиков.
Сейчас пошли по варианту, который подсмотрели в Настройка процесса отправки сообщений по MQTT-мосту - #6 от пользователя Demix Т.е. помимо изменения имени топика еще управляем частотой отправки сообщений в облако. Единственное, очень громоздкие скрипты получаются.
Не нравится мне описанный подход. Ну и модифицировать можно одной-двумя строчками в том же правиле, равно как и взводить "таймер.
А можете помочь с кодом, от которого можем оттолкнуться в вашем варианте? У меня сейчас так:
defineVirtualDevice("export", {
title: "Export",
cells: {
main_power_total: {
type: "power",
value: 0,
order: 1
},
main_energy_total: {
type: "power_consumption",
value: 0,
order: 2
}
}
});
defineRule("sendDataToServer", {
when: cron("@every 5s"),
then: function () {
dev["export"]["main_power_total"] = dev["wb-map12e_180"]["Ch 1 Total P"];
dev["export"]["main_energy_total"] = dev["wb-map12e_180"]["Ch 1 Total AP energy"];
}
});
Функцию переписать так:
function mqtt_republic(sTopic, dPath, dTopic){
defineRule("republic_"+sTopic, {
whenChanged: sTopic,
then: function (newValue, devName, cellName) {
publish(dPath+devName+"/"+dTopic, newValue, 2, false);
//log.info(dPath+devName+"/"+cellName)
}
});
}
Ну и добавить в саму функцию примитивную процедуру: Проверка, не запущен ли таймер, если запущен: ничего не делать. Если не запущен - публиковать значение и запускать таймер. Таким образом публикация не чаще чем период таймера.
Ну и значение таймера опционально передавать в функцию.