Замедление опроса отдельных каналов в новом драйвере wb-mqtt-serial

Программное обеспечение
1

Прошу прощения за некропостинг, но вопрос всё равно до конца не понятен.

Сейчас в wiki документации вы пишете:

Точная настройка периода опроса может быть полезна, если какие-то каналы нужно опрашивать часто. Значения, которые можно указать, зависят от количества каналов, которые надо опрашивать быстро, обычно это: от 200 до 500 мс на канал. Не рекомендуем использовать эту настройку для замедления опроса каналов, например, установки значений в десятки секунд — это может сильно замедлить работу драйвера, так как он не сможет оптимизировать запросы по своему усмотрению.

Хорошо, понято-принято. Но как тогда вы рекомендуете замедлять опрос? Скажем, есть MSW с детектором движения и прочими показаниями. Хотелось бы быстро (пусть и без фанатизма) отслеживать наличие движения, но получать информацию об освещённости, скажем, не чаще раза в минуту. То есть устаревший poll_interval на устройство не задать, иначе мониторинг движения может стать неактуален, но обновлять все остальные показания раз в 1-2 секунды тоже не хочется.
Не зная об этом ограничении, я просто задал интервалы опроса, которые мне были нужны (типа, основные показания опрашивать раз в минуту, serial опрашивать раз в 10 минут и т.п.). То есть, сделал интуитивно очевидные для меня настройки. И после этого можно было долго стоять напротив датчика и махать руками — он не замечал движения. Но мне и спам значений температуры 24,5°/24,6° каждую секунду, когда реальная величина где-то около 24,55°, тоже ни к чему.

Как правильно настроить опрос в таком случае? Чтобы что-то часто (пусть просто в порядке очереди), а что-то заведомо реже, на один-два порядка?

Ещё момент. Есть датчики MS v.2, где ничего такого быстрого нет, но poll_interval устарел. Как его весь правильно опрашивать раз в минуту, например? А то устарел предполагает, что когда-то от этого вообще откажутся. Но что взамен?

Вообще, у zigbee датчиков xiaomi/aqara интересно реализована отправка показаний. Если значение почти не меняется — они могут и раз в час приходить, а если меняется резко, то присылают их каждые несколько секунд. Причём, тоже имеют разрядность температуры до сотых долей градуса, но не злоупотребляют ей, сообщая об изменении на каждую сотую. Не знаю, возможно ли в принципе что-то такое реализовать, но подход к вопросу рациональный.

1 лайк
2

Думаю, можно попробовать использовать параметр rate_limit для медленно опрашиваемых параметров:

    // Задаёт максимальное число чтений регистров в секунду.
    // Не влияет на чтение регистров с заданным интервалом опроса.
    // Для снижения нагрузки на процессор рекомендуется задавать значение не более 100 для WB6 и не более 800 для WB7
    "rate_limit": 100,

Параметры описаны в репозитории: GitHub - wirenboard/wb-mqtt-serial: Wiren Board MQTT serial protocol driver

3

Спасибо, интересный параметр. Фактически, он замедляет весь цикл опроса для wb-mqtt-serial драйвера, исключения только для каналов, которым задан фиксированный период? Наверное, он больше подходит для снижения нагрузки на процессор контроллера, если цикл опроса его сильно нагружает, потому что не очень понятно во временных величинах, что в итоге получится. Значение по умолчанию для этого параметра какое? 100 для WB6 и 800 для WB7 (рекомендованный максимум)? Наверное, можно подобрать такое значение (а сколько минимум? 1?), при котором опрос всех устройств будет занимать, скажем, 1 минуту. Правда, это всё будет сильно зависеть от количества опрашиваемых устройств и их каналов с настроенным периодом опроса по-умолчанию, и при каждом изменении этого количества придётся подбирать новое значение параметра rate_limit.

Не планируете сделать что-то более простое для задания длительного, но более точного периода опроса? Или хотя бы написать рецепт, как с имеющимися параметрами этого добиться?

А всё таки, если вернуться к настройкам периода опроса конкретного канала устройства, то какие максимальные значения можно там задавать? Сейчас в интерфейсе предлагаются готовые варианты 100 и 200 мс, что как бы намекает, что, например, 60000 мс, добавленные вручную, там немного не в тему. Чтобы задать и не беспокоиться, что драйвер не будет озадачен при построении очереди запросов.

4

Да, правильно.

Хорошо, запишу ваше пожелание.

5

Хм… ну вот я поставил период опроса 60 секунд на одно из устройств и вроде ничего не сломалось, а вы пробовали это делать? Возможно, драйвер с тех пор как-то доработали, уточню.

6

Да, я поставил 60000 для read_rate_limit_ms (или «Читать не чаще (мс)») на устройство, и получил период опроса всех каналов этого устройства 60 секунд. Для некоторых каналов, которые мне нужны чаще, я явно поставил read_period_ms с более коротким периодом, чтобы эти значения поступали чаще.

Правда, чтобы убедиться, что так будет работать, пришлось поизучать исходники wb-mqtt-serial. Потому что в документации в описании конфига wb-mqtt-serial.conf сказано:

// Интервал в миллисекундах, который должен пройти между двумя последовательными чтениями канала.
// Учитывается, если не задан параметр "read_period_ms".
// Не рекомендуется к использованию, поддерживается для обратной совместимости с ранее созданными конфигурационными файлами.
// Вместо него рекомендуется использовать read_period_ms.
"read_rate_limit_ms": 10000,

А вот средствами одного только параметра read_period_ms данную задачу всё таки не решить. А если можно, то я и хотел узнать как. Получается, что рано списывать read_rate_limit_ms, что неплохо бы как-то отразить в документации.

7

А в чём затруднение? Я взял датчик WB-MSW v.3, выставил температуре период опроса 70 секунд, а сенсору движения 200 мс и всё работает хорошо: температура опрашивает редко, датчик движения моментально.

Больше никаких настроек не менял.

изображение
изображение1035×669 43.7 KB

изображение
изображение797×523 26.1 KB

8

Я немного не так делал. Разработчик всегда тестирует немного по своему, понимая внутреннюю логику работы. А я делал не понимая: использовал read_period_ms не для настройки гарантированного частого опроса, а только для замедления поступления значений. То есть, для всяких температуры, влажности, освещённости, СО2 и прочих показателей, где скорость не нужна, задал 60.000 мс интервал, а для серийного номера так вообще 600.000 мс (он же не меняется, зачем его часто опрашивать?). При этом я предполагал, что всё остальное, где период не задан, будет опрашиваться так же часто, каждые 1-2 секунды. То есть опросы с периодами 1 и 10 минут были с высоким приоритетом, а датчик движения без явных настроек — с низким. Ну и ко всему прочему у меня на шине порядка 15 штук одних только MSW v.3, да ещё столько же других устройств (реле, диммеры, MAI11, MS v.2). Возможно, злую шутку сыграло общее количество устройств (или, как минимум, количество MSW v.3) и один из приоритетных опросов с периодом аж в 10 минут. Движение в принципе могло не зафиксироваться, либо появлялось с задержкой до минуты.

Выше я как раз об этом писал.

9

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

10

Да нет, я хочу реже писать данные в MQTT, потому что они потом через bridge улетают дальше.

Поэтому, как я уже и просил, если возможно, оставьте в том числе и способ настройки «Читать не чаще (мс)» как сейчас, хоть он у вас и помечен, как нерекомендованный.

1 лайк
11

Поддерживаю. Все-таки хотелось бы на уровне отдельных каналов “замедлять”. Я в итоге из-за этой проблемы был вынужден переехать с WB6 на WB7 см. Новая логика параметров опроса wb-mqtt-serial в wb-2204
Но теперь у меня от потока MQTT начинает подыхать HomeAssistant

1 лайк
13

+1. Имел схожую проблему - WBIO-DI-HVD-8 через WB-MIO. Очень долгая реакция. Замедление посредством выставления больших значений в поле “Период опроса” вызывало торможение всех устройств на шине. А вот решение “наизнанку” (с выставлением больших значений в поле “Читать не чаще” и малых значений в нужных полях) как раз дало необходимый результат.

Но, откровенно говоря, хоть это и решает проблему, но остается ощущение, будто подпер костылем. Выглядит так, что драйвер либо багованый, либо ведет себя контринтуитивно. В любом случае, и то и другое - повод для улучшений и исправлений.

1 лайк
14

+1