Добрый день. После выхода стабильной версии wb-2606 настроил два сценария астрономического таймера, восход и закат. Действие присваивается контролу 0 и 1.
Какое то время работало стабильно. В последнее время иногда срабатывал в дневное время сценарий закат( контролу присваивалась 1). Закономерность не выявил. Вчера после обновления и перезагрузки контроллера сценарий закат не выполнился и не выполняется вручную по кнопке “выполнить сейчас”. В логах 26-07-2026 18:33:45.694 ERROR: [rule error] [WBSC-astronomicalTimer-init]: Exception during scenario initialization: "Basic VD creation failed" for scenario: "Закат" 26-07-2026 18:33:45.692 ERROR: [rule error] Virtual device "wbsc_zakat" already exists in system
Хотя сам сценарий есть в устройствах.
Где искать проблему?
Добрый день.
Разобрался с архивом: проблема в «зависшем» виртуальном устройстве wbsc_zakat, которое осталось в MQTT и мешает сценарию «Закат» пересоздаться после перезагрузки. В логе:
ERROR: [rule error] Virtual device "wbsc_zakat" already exists in system
ERROR: [rule error] [WBSC-astronomicalTimer-init]: Exception during scenario initialization: "Basic VD creation failed" for scenario: "Закат"
Сценарий «Восход» не затронут, конфиг сценариев корректен — дело именно в этом зависшем объекте.
Чтобы убедиться, что это именно он, откройте в браузере веб-интерфейс контроллера → Настройки → MQTT Channels, найдите там wbsc_zakat и пришлите скриншот этой строки.
И подскажите, как вам удобнее это исправить:
-
пересоздать сценарий «Закат» под новым именем (быстро, но нужно будет заново указать координаты и привязку к контролу), или
-
почистить зависшее устройство вручную (сохранит текущий сценарий как есть, но потребуется несколько команд по SSH).
Параллельно я пытаюсь воспроизвести эту ошибку у себя на стенде — вернусь с результатом.
filename (1).csv (2,2 КБ)
Еще заметил по истории что сценарий периодически выполняется в хаотичное время, хотя по смыслу должен выполняться в закат и рассвет.
Почистите вручную, сохранив текущий сценарий как есть:
-
Подключитесь к контроллеру по SSH.
-
Выполните команды (очищают retained-сообщения по каждому контролу из вашего скрина):
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/current_time'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/event_type'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/execute_now'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/next_execution'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/rule_enabled'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/controls/state'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/meta/name'
mosquitto_pub -r -n -t '/devices/wbsc_zakat/meta/driver'
- Перезапустите движок правил:
systemctl restart wb-rules
После перезапуска устройство wbsc_zakat в MQTT Channels появится снова. Далее проверьте:
-
на странице «Устройства» сценарий «Закат» отображается и включён;
-
кнопка «Выполнить сейчас» у него срабатывает без ошибки;
-
в логе (Настройки → Логи или
journalctl -u wb-rules) больше нет ошибки “already exists in system” дляwbsc_zakat.
Подскажите: нет ли у вас отдельного, отличного от сценариев «Восход»/«Закат», правила — в разделе Правила → Скрипты правил (или файла в /etc/wb-rules/), которое тоже управляет контролом astro_light/state? Например, если этот контрол и его логика (0 = восход, 1 = закат) были сделаны самостоятельно ещё до того, как вы настроили сценарии через веб-интерфейс, и старый скрипт не был удалён — он мог остаться активным и работать параллельно с новыми сценариями, вызывая эти лишние срабатывания.
После удаления и перезагрузки сервиса при попытке редактировать через вэб интерфейс, опять сыпятся ошибки
27-07-2026 11:21:03.338 ERROR: [rule error] [WBSC-astronomicalTimer-init]: Exception during scenario initialization: "Basic VD creation failed" for scenario: "Закат"
27-07-2026 11:21:03.336 ERROR: [rule error] Virtual device "wbsc_zakat" already exists in system
27-07-2026 11:21:02.063 INFO: reloading file: /usr/share/wb-rules-system/rules/scenario-init-main.js
После перезагрузки контроллера все заработало. Но это не дело. Давайте поймем в чем причина, что бы не было повторений.
Сформируйте и отправьте, пожалуйста, диагностику.
Архив получил. Буду воспроизводить ситуацию на стенде.
filename (2).csv (757 байтов)
Опять сработал сценарий Закат утром. Неоднократно замечено ложное выполнение сценария закат в момент восстановления интернета после ночного отключения. Получается сценарий астрономический таймер как то связан с интернетом?
Настройки времени на контролере правильные? Давайте решим скорее этот вопрос.
root@wirenboard-AXEJVKTS:~# timedatectl status Local time: Wed 2026-07-29 08:07:46 +04 Universal time: Wed 2026-07-29 04:07:46 UTC RTC time: Wed 2026-07-29 08:07:46 Time zone: Europe/Samara (+04, +0400) System clock synchronized: yes NTP service: active RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
‘timedatectl set-local-rtc 0’.
Добрый день.
Кажется, нашёл причину — и она не в контроллере. К вашему WB подключён внешний MQTT-мост с Raspberry Pi (порт 1884). Он постоянно переподключается, и каждое переподключение по времени точно совпадает с очередным ложным срабатыванием сценария.
Похоже, Pi при каждом реконнекте заново публикует своё состояние, которое пересекается с тем, что пишут сценарии «Восход»/«Закат».
Подскажите:
-
Что за Pi и какая на нём система (Home Assistant, Node-RED, свой mosquitto)?
-
Нет ли на нём отдельной, старой логики по восходу/закату?
-
Если можно — пришлите его конфиг моста (
bridge_topicв mosquitto.conf).
Добрый день. Вектор поиска неисправностей получается правильный.
Удаленный сервер mosquitto c установленным НА. Он является инициализатором подключения моста к WB. Подключение к WB идет через VPN поверх LTE сеть.
На нем в НА выведен просто binary_sensor:с конфигом:
- name: "Восход/закат"
unique_id: sinset
state_topic: "/devices/astro_light/controls/state"
icon: mdi:weather-sunset-up
payload_on: "1"
payload_off: "0"
availability_topic: "$SYS/broker/connection/raspberrypi.external-bridge/state"
payload_available: "1"
payload_not_available: "0"
Забегая вперед дело не в нем.
конфиг моста такой:
connection external-bridge
address 10.1.2.200:1884
cleansession false
topic +/# both
try_private false
remote_username хххххххххххххххххххххххххх
remote_password ххххххххххххххххххх
Стабильно воспроизводится при восстановлении моста в топик контрола astro_light/state публикуется 0.
В WB состояние контрола astro_light/state меняют только правила закат и восход. Каким образом подключение моста может влиять на сценарии?
На удалённом брокере (на Pi) копится своя собственная retained-копия этих топиков (просто потому что мост когда-то их туда зеркалировал). Мост нестабильный (VPN поверх LTE), постоянно рвётся и переподключается. При каждом реконнекте, поскольку канал двусторонний (both) и сессия персистентная (cleansession false), брокеры обмениваются retained-сообщениями заново — и устаревшее значение с Pi перезаписывает актуальное на WB. При восстановлении моста в astro_light/state стабильно прилетает “0”, и прилетают устаревшие retained-топики /devices/wbsc_zakat/# — из-за чего наша вчерашняя чистка не держалась: мы чистили WB, а через минуту мост реконнектился и притаскивал старьё обратно с Pi.
Исправление — сузить топик и сделать его однонаправленным:
topic /devices/astro_light/controls/state out
Всё остальное через мост гонять не нужно — особенно /devices/wbsc_zakat/#, который туда вообще не должен попадать.
Не получится. По мимо этого между мостами многое передается, в том числе и управление. Мост давно используется.
Можно ли настроить мост так, что бы инициализатором был WB и при коннекте он переписывал топики на удаленном брокере а свои не трогал?