Здравствуйте.
В котельной стоит WBIO-DI-HVD-8, подключенный к WB-MIO для контроля напряжения на насосах и котле (управляется через реле, которое висит прямо там же дальше по шине). В прошлый отопительный сезон все было ок.
С началом нового отопительного сезона заметил, что время реакции на события (вкл./выкл. насосы или котел) стало неимоверно высоким - новое состояние начинает отображаться через несколько минут! Если физически отключить модуль WBIO-DI-HVD-8 от WB-MIO, то в интерфейсе он так же станет “красным” через несколько минут (и так же перестанет быть красным спустя несколько минут после возвращения на место). Реле, которое висит дальше по шине, реагирует моментально.
Скажите, в какую сторону вообще копать? Как диагностировать?
Добрый день.
Для начала - какой релиз ПО на контроллере?
Настроены ли приоритеты опроса каналов, если да - то как? Ну и, в любом случае минуты - это прямо очень, очень много.
В общем выложите файл /etc/wb-mqtt-serial.conf и архив с диагностической информацией контроллера. Создание архива описано в документации.
Проблема оказалась еще более странной. Что я делал:
Мне от вас прибыл еще один заказ, в котором был еще один WBIO-DI-HVD-8 и WB-MIO. Я их подключил, все нормально работает.
Я поменял местами детекторы WBIO-DI-HVD-8. Новый детектор перестал работать на старом месте, старый детектор стал работать на новом месте → проблема не в WBIO-DI-HVD-8. Настройки были все по дефолту, только адреса прописаны.
Потом я заметил, что новый модуль WB-MIO довольно интенсивно мигает зеленым светодиодом. То же самое делают и реле в разных других щитах. А вот старый модуль как раз-таки мигал один раз в несколько минут. И я обратил внимание, что остальные устройства в этом щите в котельной на той же шине (MR6CU, MCM8 и MSv2) просто “горят”. Решил проверить, и, действительно - MCM8 которое у меня мониторит открытие окон и дверей, не реагирует сразу. Все эти устройства сидели на одной обособленной шине → проблема затрагивает всю шину целиком. Но странность в том, что реле, хоть и не мигало светодиодом, но на команды откликалось моментально. Делаю предположение, что каким-то образом нарушилось именно получение данных от устройств, а подача команд проходила нормально.
Хотел подготовить архив, который Вы просили, решил перед этим “подчистить” конфиг и убрать опрос неиспользуемых входов и параметров устройств, и, вуаля - всё заработало, все устройства “замигали”. Я ничего не менял в настройках самой шины (ни когда-либо, ни сейчас, всё по дефолту), просто убрал неиспользуемое. Странность же в том, что после того, как я, в попытках воспроизвести проблему, вернул все обратно, проблема-то не вернулась.
Т.е. на данный момент проблема не наблюдается. Исправлена ли она - неизвестно, п.ч. нет понимания причины. И пока мне больше нечего сообщить. К сожалению или счастью
Так, предполагаю что (возможно) был включен опрос несуществующего канала (каналов), с огромным временем ожидания ответа. Вот он-то и останавливал опрос. А отправка новых значений на реле - она имеет приоритет и происходит сразу же.
Вот оно, Вы правы.
После вашего последнего комментария я вспомнил, что в попытках воспроизвести проблему я на самом деле вернул на место не всё - у меня был добавлен MSWv3, который физически был отключен. Сейчас проверил, вернул его конфигурацию, и обмен данными снова встал.
Хотя, время опроса каналов этого несуществующего датчика было по дефолту - “в порядке очереди”.
Выходит, что отключенные устройства могут приносить проблему всей шине? А если, допустим, где-то отошел контакт?
Сейчас подключил MSWv3 на другую шину. С настройками опроса по умолчанию все работает ок. Но стоит только выставить опрос, например, температуры раз в минуту (60000ms), то возникает похожая ситуация - все устройства на той же шине начинают слоупочить. Несуществующих устройств на этот раз нет. У датчика отключено чтение вообще всех других каналов, кроме температуры, влажности и движения. Проверил несколько раз.
Теперь я запутался и не понимаю, как работает этот параметр “Опрос”…
Напомните, а чем не устраивают настройки по умолчанию? В драйвере есть недоработка, из-за которой большие числа в периоде опроса мещают ему оптимизировать запросы и он работает не так, как хотелось бы. Пока непонятно, как это исправить и не навредить его основной фишке — глубокой оптимизации запросов для ускорения опроса.
Поэтому сейчас мы рекомендуем для медленных каналов использовать опрос в порядке очереди, а для тех, где нужна мгновенная реакция выставлять опрос 200–500мс.
Подробнее можно прочитать в документации, которую мы поправили, чтобы не вводить в заблуждение.
Напомните, а чем не устраивают настройки по умолчанию?
Спойлер
Я заметил, что опрос датчика температуры и влажности “в порядке очереди” хорошо так способствует росту размера файла базы данных в Home Assistant. Если с каналами датчика движения все просто - тупо настраиваем Recorder в Home Assistant и вообще не храним эти значения, то с температурой и влажностью так делать особо нет смысла (в чем смысл мониторить температуту, если нельзя посмотреть ее историю?..). Учитывая, что температура в помещении очень инертна и меняется весьма медленно, нет смысла опрашивать ее так часто. Достаточно раз в минуту (а то и вовсе раз в минут 5).
Подробнее можно прочитать в документации, которую мы поправили, чтобы не вводить в заблуждение.
Как пользователь, я бы предложил также добавить какую-нибудь подсказку к этому полю в web UI, которая будет предупреждать пользователя о возможных последствиях при вводе больших значений.
Как разработчик, я бы предложил при разборе wb-mqtt-serial.conf добавить вывод какого-нибудь WARNING в лог в таких случаях.
Подрезюмирую свою ситуацию:
Есть две разные шины RS-485.
На одной висит датчик MSv2 (температура + влажность), опрашивается раз в минуту. И всё работает хорошо, остальные устройства опрашиваются быстро, а датчик - раз в минуту, как и хотелось.
На второй шине висит MSWv3 (температура + влажность + движение). В порядке очереди все работает как надо, но если выставить на опрос в минуту только часть каналов (температура + влажность, НО не движение), то тормозит вся шина.
Я пытаюсь понять, действительно ли это ожидаемое поведение (known bug), или же это какая-то другая проблема именно в моей конфигурации/железе. Если первое, то хочется поточнее определить границы, т.е. условия для возникновения проблемы (п.ч. в моем случае и там и там опрос раз в минуту, но проблема только на одной шине).
