Добрый день.
Контроллер WB 8.5.2, к первому RS-485 подключен WB-M1W2 в режиме дискретного входа по обоим входам. Изменения состояния входов происходит крайне редко. В настройках wb-mqtt-serial включен “Интервал публикации неизменившихся значений“, установлено значение 10 сек.
В “Каналах MQTT” вижу, что состояние регистров датчика WB-M1W2 опрашивается штатно, горит Ок. Но состояния регистров в брокере не приходят на постоянной основе.
Подписывался на нужные топики (локально). События не приходят, точнее приходят при изменении состояния, а промежуточные значения приходят крайне редко (раз в полчаса-час) по непредсказуемой логике. Изменение “Интервал публикации …” в значение 0 принципиально ничего не меняет.
Как настроить обязательную передачу состояния регистров в MQTT даже при неизменяемых значениях?
Добрый день!
В /etc/wb-mqtt-serial.conf проверьте “max_unchanged_interval”: -1, (ссылка).
Для гибкой настройки истории хранения вам поможет описание работы истории и базы данных:
А для чего? То есть в чем состоит цель?
При неизменном состоянии публиковать - просто создавать спам.
Проверил.
Значение этой переменной в файле соответствует заданному мной в “Интервал публикации неизменившихся значений” в интерфейсе.
Установил в интерфейсе 0 - Ноль задает публикацию после каждого чтения данных из устройства, в файле вижу:
{
“debug” : false,
“max_unchanged_interval” : 0,
….
Это не решает проблему НЕпередачи в топики статичных данных при каждом чтении или по таймеру. Я неправильно понимаю назначение этого параметра? Как можно исправить?
Мне не нужно решить задачу хранения данных в базы локально на контроллере, мне требуется стабильно передавать данные “наружу“. Настроен Telegraf, который пушит данные в формате Prometheus и далее Grafana визуализирует. А разрывы в серии данных ломают всю логику визуализации и обработки алармов.
Извиняюсь, не ответил всем сразу.
Понимаю вашу позицию. Свою задачу описал выше. Если вы знаете, как работает описанная мною связка сервисов, то вопросов возникать не должно. Мне нужно отключить “оптимизацию“, когда она не требуется.
Проверил в grafana:
Публикация только по изменениям, конечно.
В случае неизменяющихся данных - никаких “перерывов” нет, значение отображается.
Если меняется - то соответственно и отображается.
Неверно.
Как описано в документации
// Задаёт интервал в секундах, в течение которого неизменяющиеся значения не будут публиковаться в MQTT.
// По истечении интервала (но не чаще периода чтения канала) полученное значение будет опубликовано, даже если оно не изменилось.
В случае использования Быстрого Modbus - значения не читаются. Модуль сам отдает их, точнее отзывается на опрос.
Параметр, в общем, имеет смысл только для устройств работающих на классическом опросе.
Да, так и реализуется.
Но смысла передавать неизменные данные - просто нет. Они не меняются, для чего их передавать и записывать в базу?
Знаю, ну, на уровне Использование Grafana с контроллером Wiren Board — Wiren Board по крайней мере.
Добрый день.
Могу предположить, что в вашем примере изменения есть всегда, поэтому график гладкий. Это температура, количество знаков после запятой надо проверить.
В моем представлении метрик prometheus из хранилаща VictoriaMetrics графики в Gfarana выглядят так:
И меня это не устраивает. По таким выборкам нельзя настроить в Grafana правила алармирования, например.
Не знаю как получилось, но сейчас при установленном параметре “Интервал публикации неизменившихся значений” в 20 секунд, я получаю стабильную отправку в топик первого входа датчика WB-M1W2 его неизменное состояние 0 каждые 20сек:
mosquitto_sub -v -t “/devices/wb-m1w2_232/controls/Input 1”
/devices/wb-m1w2_232/controls/Input 1 0
/devices/wb-m1w2_232/controls/Input 1 0
/devices/wb-m1w2_232/controls/Input 1 0
/devices/wb-m1w2_232/controls/Input 1 0
/devices/wb-m1w2_232/controls/Input 1 0
/devices/wb-m1w2_232/controls/Input 1 0
Далее связка сервисов отрабатывает штатно, график в Grafana такой, как я ожидаю.
НО, по второму входу не приходит ничего до момента изменения его состояния.
Как это можно объяснить?
Можно на датчике принудительно отключить “Быстрый Modbus”, чтобы работало в “классическом” запрос-ответе?
Проверил, по истории контроллера. Нет, публикации не было.
Я не использовал prometheus
InfluxDB специально разработана для хранения временных рядов. Поэтому, предполагаю и поведение с ней ожидаемое.
Для контроля связи какой-то из каналов устройства всегда опрашивается классически. Выбирается случайно.
Не проще ли в grafana риспользовать опцию “Fill missing values with previous value” (Заполнить отсутствующие значения предыдущими значениями)
Для подобного нужно поменять/переписать шаблон.
Ну и пересчитать/перенастроить времена запросов для устройства и в целом для шины.
Я бы не рекомендовал такой путь.
Можете использовать для отправки данные из виртуального устройства, в которое публиковать с любой удобной частотой.
Здравствуйте.
На текущий момент я получил необходимую мне логику работы. Работает стабильно.
1.Установил “Интервал публикации неизменившихся значений” в 30 секунд
2.В шаблоне config-wb-m1w2-buttons.json в разделе “channels“ у нужных мне метрик параметр “sporadic” установил в “false”
3.Нужные мне метрики отпрашиваются в режиме “в порядке очереди“
Отдельное спасибо разработчикам, что заложили возможность отключения работы по событиям.
Теперь графики “гладкие“ и я могу настроить в Grafana алармирование по проверке связи с датчиком по наличию данных от него, как уже у меня реализовано с другими датчиками.
Итого - проблема решена.
Остался вопрос: какие есть минусы при использовании такого подхода и на что обратить внимание?
На то, как утилизируется сейчас шина.
Например - классический опрос 20 регистров на скорости 9600 займет 0,8-1 секунду.
