1.Скрипты стали копиться, стало сложнее помнить где и что вызывал\использовал.
2. А также косвенная причина - это как будто “самопроизвольное” переключение выхода (света).
Во многих IDE есть поиск по всему проекту\папке, так называемый cross-reference, также такой поиск есть банально в Notepad++.
WB-ИИшка подсказывает, что можно использовать grep, я проверил - работает, но для меня лично это не очень удобно.
Какие есть идеи, как можно организовать поиск “по всем скриптам”? Настроить доступ в папку по сети и искать чем угодно? Как в таком случае лучше безопасно настроить доступ к папке /wb-rules и другие для доступа из-под Windows?..
Т.к. опосредовано П1 вызван тем, что свет самостоятельно выключился, требуется проверить - не “виноват” ли скрипт, не срабатывал ли вход (настроена работа по матрице), может быть у меня перепутан вход и т.д. - как лучше “поймать” такое изменение?.. Добавить скрипт-логгер соответствующего входа и выхода?..
Предварительно есть основания полагать, что на вход 0 назначено “выключить все выходы” (проверю) и этот вход подключен на клавишу на входе в ванной и при его нажатии выключается свет и в спальне (моя ошибка).
Судя по всему, т.к. у меня по освещению решение типовое - входы и выходы по mapping матрице - как в таком случае “сегрегировать” в логах сработку по входу от сработки с помощью скрипта?.. Уже был подобный вопрос на форуме, только я не понял как лучше реализовывать)
И в целом вопрос - как логировать работу изменения выходов в скриптах (ну тут более-менее понятно: следующей строчкой после изменений выхода), и работу самого модуля реле?
Это самое удобное, на мой взгляд. Можно попробовать монтировать папку wb-rules по SSH как отдельный диск с помощью SSHFS (сам не пробовал), возможно, есть и коммерческий софт. Но VS Code + Remote SSH кажется мне самым хорошим вариантом.
Я бы посоветовал сначала изолировать проблему: выключить все правила, а потом включать по одному. А потом уже писать в лог в потенциально проблемных местах.
Я бы смотрел за счетчиками нажатий соответствующего входа: изменились – значит, кнопка. Не изменились – команда.
Лога работы модуля реле, конечно, нет, есть только команды и запросы/ответы состояния модуля, все это можно отслеживать, если включить отладку wb-mqtt-serial, но это непростой процесс, парсить логи, находить команды, декодировать их…
Спасибо, выглядит неплохо.
Кажется, у вас профессиональная “сборка” для программирования)) может поделитесь интересными фичами/скриптами, которые реализовали?)
А это… дебаг консоль и перезапуск скриптов в VS Code - можно?)
Может еще и Watch какой-то можно?)
Ну, в принципе пока вывел через Terminal через journalctl -u wb-rules -f… Тоже пойдет
Обратил внимание, что правила сами сохраняются через VS Code… А при сохранении - сами выполняются в WB… Можно ли отключить автосохранение? Хотел бы больше контроля - самому сохранять и контролировать ход выполнения
С дебагом странная история тоже.
Настраиваю логи и тоже думаю, почему я не вижу дебаг сообщений?
тему уже поднимали.
Документация непрозрачная: log.{debug,info,warning,error}(fmt, [arg1 [, ...]]) выводит сообщение в лог. В зависимости от функции сообщение классифицируется:
debug — отладочное, выводится только при включённой отладке;
Отладка включена, дебаг (в syslog) не выводится))
Дебаг делаю через консоль…
У меня нет особенных изысков) Большие вещи – через github обычно. Код можно править локально, отправлять в репозиторий, а затем из репозитория забирать туда, где будет выполняться – это и контроль, и история правок, и резервная копия. Наверное, это самое удобное, что я еще использую. В VSCode достаточно много плагинов, часто находится что-то, что “а вот хочу такое”. ИИ-агенты удобно подключаются, нпример.
Я чаще всего открываю веб-консоль контроллера с дебагом в одном окне, а во втором VSCode – но это вопрос привычки. Автосохранение можно отключить в меню File → Auto Save (снять галочку) или в File → Preferences → Setting найти поиском “Auto Save” и выбрать подходящие параметры.
Отладочные сообщения wb-rules исторически не попадают в системные логи, поскольку их может быть очень много, когда много правил.
В debug выводится очень много отладочной информации, кроме сообщений log.debug(), я бы не стал его включать вообще без необходимости. На скриншоте привер вывода. Вывод debug-сообщений включается ключом -debug при старте движка, без него вывод log.debug() не увидеть.
