Wb-mqtt-serial с новым планировщиком опроса регистров

А вот у меня реальный объект, на котором есть система работающая сейчас в режиме Stable.
И вот поэтому(что есть реальный объект, а не тестовый стенд) я сильно сомневаюсь и даже побаиваюсь ставить данное обновление и потом всё это дело оставлять в режиме testing.

Как считаете можно ли поставить обновлённую службу на оборудование конкретного объекта и потом оставлять систему на testing или всё-таки не стоит?

1 лайк

На объекте - лучше уже когда текущий релиз станет stable.
Просто потому что тестинг пока не заморожен - и могут быть баги.

Проверил на WB6.6 с 10-ю WB-MR6C на скорости 115200
для каждого из 6 входов опрос в 1ms
Ошибок в log не сыпет, но и ожидаемого эффекта не получилось.
Хотелось сделать быстрый опрос нажатий, чтобы не было пропусков по Input.

Тем не менее разница ощутимая есть в длительности нажатия на кнопку с гарантированным считыванием

Уже близко к желаемому

К сожалению, организовать опрос каждого входа раз в 1мс технически не получится. Если устройство отвечает мгновенно, и контроллер тоже мгновенно шлёт следующий запрос, один цикл опроса входов на одном устройстве занимает не менее 2мс. Дополнительно текущие прошивки MR6C требуют 8мс задержки перед опросом, в результате получаем чуть меньше 10мс на устройство. У вас 10 устройств, т.е. в идеале чаще, чем раз в 100мс, значения входов не получить. В реальности период будет ещё больше, т.к. есть время ответа устройства, время обработки в контроллере и опрос других регистров.

1 лайк

но человек в любом случае задержку меньше 50мс не заметит

Если бы я такой низкокругозорный ответ прочитал бы до покупки умного дома на WB - я бы его точно не покупал. Извините, но cy6appum высказывает дельное мнение, которое очвидно с моей стороны, при этом делает это в максимально коректной форме, в то время как вы не желаете слышать. Чем больше таких нежелающих слышать в вашей компании тем меньше время жизни вашего продукта.

Да, мнение - дельное.
Именно с учетом такого развития - и придумана система релизов, которая позволяет остаться на каком-то из них.
Но сохранять жесткую совместимость - это просто закостенеть. Те же гибкие конфиги - они невозможны к использованию в старых версиях wb-mqtt-serial, со старым wb-mqtt-homeui.
Разработка ПО для новых возможностей неизбежно приводит к тому, чтонесовместимость. Это естественный процесс. Поэтому, прежде чем что-то обновлять нужно для себя решить:

  • плюсы обновления
  • Что нужно сохранить (конфиги) для возможности быстро откатиться
  • план обновления

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

Спасибо за пояснения, они гораздо понятнее и благозвучнее, хоть и не меняют суть дела.

Тема тайминга безусловно важна, для меня, как для простого обывателя, тема двойного и длинного нажатия при управлении светом по-прежнему актуальная - не хочется на стене размещать “пианино” - некрасиво и неудобно.

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

Благодарю, стараюсь быть понятым, приятно.

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

А старые конфиги в новой - и можно и нужно, тут нет предмета для споров.

Так “старые” и поддерживаются, механизм установки произвольных регистров не выпиливался.

Ээ. А о чем тогда спор?!
Меня триггернуло то, что было процитировано в первом моем ответе.
Если новые фичи не рушат совместимость со старыми, - я с вами, но никак не против вас.

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

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

1 лайк

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

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

Поэтому мы решили старый poll_interval сделать deprecated и сделать два параметра - один для настройки периода опроса приоритетных быстрых регистров, другой - для запрета опрашивать регистры чаще, чем указано. Обратная совместимость во втором сценарии будет.

@cu6apum я же правильно понимаю, что лично у вас ваша конкретная задача - ближе ко второму сценарию?

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

Конкретных задач бывает много. Да, мне в большинстве приложений важнее всего отказоустойчивость, что есть меньше жевать диск (retained я выключить не могу). В некоторых наоборот важнее скорострельность.

Вопрос был не в этом (хиба ж я не настрою), а в совместимости со старыми конфигами на случай апгрейда малоквалифицированным персоналом: чтоб не обвалить сетап. Ответ на него я получил постом выше и полностью удовлетворен.

Обновили планировщик опроса Modbus-устройств в драйвере wb-mqtt-serial

:memo: Теперь вы можете задать желаемый период опроса и драйвер будет стараться его выдержать, а если заданный период выдержать не получится — он сообщит об этом в карточке устройства.

:orange_book: Новый параметр похож на старый Poll Interval, но работает по другому: раньше драйвер опрашивал канал не быстрее, чем указано, а теперь старается точно уложиться в период. Есть обратная совместимость, поэтому в инсталляциях ничего не сломается.

:white_check_mark: Точная настройка периода опроса может быть полезна, если какие-то каналы нужно опрашивать часто или наоборот — редко. Для ускорения опроса рекомендуем устанавливать значения не меньше 100–300 мс и не более, чем для 10-15 каналов на порт. Здесь нужно учитывать, что драйвер оптимизирует запросы, например, состояние всех шести входов одного реле он может считать за один раз, а значит максимальное количество каналов нужно подбирать опытным путём и оно может быть сильно больше 15 штук.

:gear: Чтобы указать интервал опроса, перейдите в веб-интерфейсе в настройки драйвера serial устройств и укажите желаемый период опроса для любого канала или устройства целиком.

:hammer_and_wrench: Новый планировщик уже доступен в текущем testing, будем рады замечаниям и предложениям.


Настройка периода в веб-интерфейсе контроллера

ksnip_20220315-121205
Предупреждение о том, что выбранный период выдержать не получается

3 лайка

9 сообщений были перенесены в новую тему: Поведение wb-mqtt-serial при ошибках записи

11 сообщений были перенесены в новую тему: Замедление опроса отдельных каналов в новом драйвере wb-mqtt-serial