Grafana: Сбой интеграции с WirenBoard – активация реле после рестарта сервера

[vova02]

Здравствуйте!

Обращаюсь в службу поддержки по поводу возникновения проблемы в процессе сбора метрик с WirenBoard 7 посредством Raspberry Pi 4B, на котором установлены Grafana и InfluxDB (без использования Docker).

1. Конфигурация оборудования и программного обеспечения:

• Raspberry Pi 4B:
  • Установлен чистый образ системы, Raspberry Pi OS x64 Lite.
  • На устройстве установлена нативная (без Docker) версия Grafana.
  • Для хранения метрик используется InfluxDB.
  • Кроме ПО из вашей инструкции - ничего стороннего не установлено.
• WirenBoard 7:
  • Работает на прошивке wb-2407 stable.
  • С устройства собираются метрики для дальнейшей визуализации в Grafana.

2. Ход установки и настройки:

• Следовал официальной инструкции по ссылке: Использование Grafana с контроллером Wiren Board — Wiren Board.
• На Raspberry Pi установлен MQTT брокер.
• На WirenBoard настроен MQTT мост.
• После установки Grafana и InfluxDB на Raspberry Pi 4B настроен сбор данных с WirenBoard 7.
• Все данные успешно передаются, а графики в Grafana отображаются корректно.

3. Описание возникшей проблемы:

• Суть проблемы:
  После перезагрузки Raspberry Pi 4B наблюдается, что на устройстве WirenBoard 7 срабатывают определённые реле.
• Конкретные наблюдения:
  • Реле wb-mrm2-mini_96/K1 и wb-mrm2-mini_96/K2 активируются сразу после перезагрузки Raspberry Pi.
  • Есть вероятность, что срабатывают и другие реле, однако внимание привлекли именно данные, так как они управляют гаражными воротами.
• Последствия:
  • Непреднамеренное срабатывание реле приводит к запуску механизмов, связанных с гаражными воротами, что может создавать потенциально опасные ситуации и приводит к нежелательным действиям.

4. Дополнительные детали:

• Проблема возникает исключительно после перезагрузки Raspberry Pi – в штатном режиме работы, когда устройство уже запущено, срабатывания реле не фиксируются.
• Передача данных и отображение графиков в Grafana работают стабильно, без ошибок.
• Подозреваю, что возможно, при перезагрузке Raspberry Pi происходит отправка каких-либо команд или изменение состояния, что приводит к активации реле на WirenBoard.

5. Вопросы для уточнения и просьба о помощи:

• Может ли быть, что в процессе перезагрузки Raspberry Pi происходит рассылка сигналов или команд на WirenBoard, которые инициируют срабатывание реле?
• Какие настройки или конфигурационные параметры на стороне Raspberry Pi или WirenBoard могут влиять на подобное поведение?
• Требуется ли внесение дополнительных корректировок в настройках связи между устройствами (например, в MQTT брокере/мосте) для предотвращения непреднамеренной активации реле?
• Можете ли вы предоставить рекомендации или необходимые шаги для устранения данной проблемы?

Прошу вас провести анализ ситуации и предоставить подробные инструкции по её устранению, чтобы избежать потенциально опасных последствий.

С уважением,
Владимир

[vova02]

Заметил следующую странность. При перезапуске Raspberry PI, заметил, что на NodeRed установленный на контроллере в дебаг приходят данные. Почему так?

[vova02]

Предполагаю, что проблема связана с тем что после перезагрузки Raspberry Pi, скорее всего, брокер автоматически отправляет последнее сохранённое сообщение для каждого топика.

Кроме того, в конфигурации моста указан режим двустороннего соединения (параметр both ). Хотелось бы уточнить, почему выбран именно этот режим в инструкции по установке Grafana?

Прошу разъяснить данный момент по настройке моста.

[BrainRoot]

Добрый день.

@vova02

Суть проблемы:
После перезагрузки Raspberry Pi 4B наблюдается, что на устройстве WirenBoard 7 срабатывают определённые реле.

Предполагаю что проще всего продиагностировать - подписаться на топики, ну например

mosquitto_sub -v -t /devices/#

на корень рекурсивно и отправить устройство raspberry в перезагрузку.
Можно определить что и куда пишется.

@vova02

• Подозреваю, что возможно, при перезагрузке Raspberry Pi происходит отправка каких-либо команд или изменение состояния, что приводит к активации реле на WirenBoard.

Да, если в /on топики что-то записывается - то это вероятная причина.

@vova02

• Может ли быть, что в процессе перезагрузки Raspberry Pi происходит рассылка сигналов или команд на WirenBoard, которые инициируют срабатывание реле?

Да, возможно, конечно.

@vova02

• Какие настройки или конфигурационные параметры на стороне Raspberry Pi или WirenBoard могут влиять на подобное поведение?

Если что-то публикуется в топики, прямо или косвенно (через скрипты, например) управляющие устройствами - то они (устройства) должны срабатывать. Это ожидаемое поведение.

@vova02

• Требуется ли внесение дополнительных корректировок в настройках связи между устройствами (например, в MQTT брокере/мосте) для предотвращения непреднамеренной активации реле?

Не могу сказать. Не знаю что именно подобное выхывает.

@vova02

• Можете ли вы предоставить рекомендации или необходимые шаги для устранения данной проблемы?

Да, могу попробовать разобраться. Покажите пожалуйста чать проекта, где описывается взаимодействие систем.

@vova02

Предполагаю, что проблема связана с тем что после перезагрузки Raspberry Pi, скорее всего, брокер автоматически отправляет последнее сохранённое сообщение для каждого топика.

А откуда у брокера это “сохраненное сообщение”?

@vova02

Кроме того, в конфигурации моста указан режим двустороннего соединения (параметр both ). Хотелось бы уточнить, почему выбран именно этот режим в инструкции по установке Grafana?

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

[vova02]

Я следовал вашей инструкции шаг за шагом, не отклоняясь ни на йоту, но в итоге столкнулся с проблемой, которая, похоже, связана с тем, что брокер после перезагрузки отправляет “сохранённые сообщения”. Вы говорите, что неясно, откуда они могут поступать, но это может быть как раз из-за включенной опции persistence true , которая заставляет брокер сохранять последние сообщения. После перезагрузки он их снова отправляет. Так же возможно, что дело в retained-сообщениях.

Кроме того, в инструкции указан двунаправленный мост - both, это бессмысленно для Grafana и как оказалось не безопасно. В такой настройке сообщения могут передаваться в обе стороны, что, как оказалось, вызывает неожиданные проблемы. Я поменял мост на однонаправленный - out , чтобы избежать отправки данных обратно, так как для данного проекта это ненужно (подчеркиваю – для создания стороннего локального сервера Grafana).

Меня возмущает, что инструкция

не предназначена, в общем для использования “как есть” в проектах.

Если инструкция предоставляется, она должна быть работоспособной и безопасной, а не оставлять пространство для ошибок и проблем.

Чтобы пояснить, что я имею в виду, вот пример: после того как Raspberry Pi перезагрузился, он отправил некорректные данные, что привело к открытию гаражных ворот. Хорошо, что я был дома и сразу заметил это, а вот если бы меня не было, даже не могу представить, к чему это могло бы привести. А ведь речь не только о гаражных воротах.

Надеюсь, вы сможете дать более чёткие рекомендации и уточнить эти моменты в инструкции. (Для инструкции «Свой сервер Grafana»).

PS: А где в инструкции сказано, что

Она не предназначена, в общем для использования “как есть” в проектах.

?))).

Проблема решилась заменой параметра both на out.

[BrainRoot]

@vova02

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

Инструкция - пример настройки.
То есть если ее выполнить - данные в графане будут.
В ней не учтены ситуации перерывов связи, перезапусков сервисов и прочее - это демонстрационный пример.
Точно так же как в примерах скриптов нет учета возможных ошибок и их обработки.

@vova02

Кроме того, в инструкции указан двунаправленный мост - both, это бессмысленно для Grafana и как оказалось не безопасно. В такой настройке сообщения могут передаваться в обе стороны, что, как оказалось, вызывает неожиданные проблемы. Я поменял мост на однонаправленный - out , чтобы избежать отправки данных обратно, так как для данного проекта это ненужно (подчеркиваю – для создания стороннего локального сервера Grafana).

Проверил у себя. При перезапуске хоста с удаленным брокером - он ничего не публикует в брокер контроллера.

@vova02

Меня возмущает, что инструкция

не предназначена, в общем для использования “как есть” в проектах.

Если инструкция предоставляется, она должна быть работоспособной и безопасной, а не оставлять пространство для ошибок и проблем.

Любая инструкция - это не набор команд, это памятка для того чтобы иметь представление о принципах реализации. Если смысл настроек не до конца понятен - не стоит ее применять “как есть”.

@vova02

Надеюсь, вы сможете дать более чёткие рекомендации и уточнить эти моменты в инструкции. (Для инструкции «Свой сервер Grafana»).

Это хорошее замечание.
Дополнил: Использование Grafana с контроллером Wiren Board — Wiren Board

[vova02]

@BrainRoot

Проверил у себя. При перезапуске хоста с удаленным брокером - он ничего не публикует в брокер контроллера.

Возможно, публикации ловил NodeRed! И на скринах я Вам это показал.
По-моему мнению, лучше исправить both на out в инструкции, так как для Grafana нет смысла иметь двустороннюю связь.
Спасибо за обратную связь!