Использование runRules

Здравствуйте!
Как я понял, любые обращения к объекту dev лучше производиться из функции then в определение правил. Т.е. все рабочие скрипты должны быть обернуты в правило.(кроме объявления функций).
Мне надо, чтобы правило срабатывало без каких-либо условий.
В документации нашел функцию - runRules. Написано, что может быть использовано в обработчике таймеров. По логике, похоже, что это то, что мне нужно. Но не нашел ни одного примера, как эту конструкцию использовать.

  1. Правильно ли я понял, что если я рабочую часть скрипта оберну в правило, то проблемы с зависанием при обращении к dev уйдут, т.к. москито уже все обработает?
  2. Правильно ли я обратил внимание на runRules для этой цели, и можно пример использования?
    Я предположил, что смогу описать правило через defineRule, обернуть в нем в then работу скрипта, а ниже вызвать это правило - запустить.

Я, конечно, сейчас буду сам экспериментировать, но хотелось бы получить компетентный ответ.
Я не понимаю синтаксис. Что писать в определении условий запуска этого правила, где указывать имя правила… в общем, нужен пример.

Возможно вы что-то делаете не так. Можете написать, какую задачу вы пытаетесь решить?

я уже в двух темах писал об этой проблеме, надеюсь, меня правильно пойму. Я не пложу темы, просто решение вопроса в разных плоскостях высплывает…

У меня есть скрипт, который после ребута завешивает движок.
Мне порекомендовали любые обращения к dev производить из then функции в определении правил.
А мне надо, чтобы по состоянию ползунка вирт. устройства включалась или не включалась работа. Мне кажется, причина в этой части, что только вирт. девайс создался, топики еще не происались, а я к ним обращаюсь. и все крашится.
Вот ищу способ как, создав в скрипте вирт устройство (а другого способа нет - только в скрипте), безопасно обратиться к его контроллам.

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

Значит что-то не то с вашим скриптом. Выкладывайте весь скрипт сюда.

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

Давайте лучше пример из жизни, по такому описанию все еще непонятно, что хотите сделать.

WatchDog.txt (3.4 КБ)

Движок правил вылетает у вас на строчке:
dev[RN + "/" + "time"] = INTERVAL;
Так как устройства dev[“name”][“time”] еще не существует.

То есть вы сначала инициализируете объект:
var WD = new WatchDog("WatchDog",1000,"wb-gpio/V_OUT");

А затем создаете нужные для него виртуальные устройства:
WD.main();

Вот оно и не работает.

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

Теперь у меня не зависает, но и не работает. Пропускаются правила. Я учел то, что вы мне писали и не только вы. Обращаюсь внутри правила после then. инициализирую вирт девайс или если он уже есть - то просто обращаюсь к полю, вижу его значение. А правила скипятся.
WatchDog.txt (3.7 КБ)

дополнение: все-равно зависает после ребута.

Как-то все сложно. По-моему проблема

Программно-аппаратный ватчдог. Циклически с периодом time включает на полпериода выход output и на полпериода его отключает.

решается элементарным cron-правилом. Кстати, вы таких вотчдогов хотите несколько создавать?

по cron- правилам я ничего сходу не нашел. видел пример every и т.д. применять его тут не стал. На этой простой задаче я обкатываю алгоритм построения правил, вообще работы со скриптами в wb. Не слать же мне большие скрипты, и вообще не делать же их, чтобы по сто раз переделывать…
Вы правы. Простая функция. Да, хочу несколько. И есть другие скрипты, где по нескоколько других объектов вызывается, не ватчдогов.
Но я не могу эту простую задачу решить, чтобы работало нормально, без зависонов. В указанной парадигме, а не простыней.

Вот пример cron-правила

понял, спасибо, сохранил себе.
Я подобное видел, но не видел списка возможных вариантов. Потому и не стал использовать.
На будущее сохраню, но моя проблема немного в другом. Не “как создать периодическое правило просто”. А как заставить не виснуть то, что виснуть не должно.
Пока что так работает и не виснет при ребутах. Но я там и не понял с вирт девайсами, надо ли их каждый раз создавать, если они уже есть. И раньше вылетали ошибки, правила скипились, теперь не вылетают, но вроде ничего такого не делал %(.
Вроде решился вопрос, но нет четкого понимания “как должно быть”. Прямо чудеса какие-то…
WatchDog.txt (3.4 КБ)

Моё мнение, что для WB - чем проще и линейнее описан код правила, тем лучше. Без всяких замыканий, наследований, обёрток и т.п.

Попробуйте первую версию сделать попроще. Просто определить виртуальные девайсы в начале скрипта и добавить правила ниже.

ясно, я тоже так думаю. Потому наследований никаких не делаю. Только “размножаю”) Хочется, чтобы хоть какие-то блоки были, а не портянка. Мне потом сложно поддерживать и модифицировать.
Ночь отработал, не подвис, надеюсь разработчики ответят в теме про диагностику, чтобы я мог предупреждать негативные последствия, а не бегать как ужаленный, когда он упадет…
Спасибо за участие!

а вы знаете, как остановить cron-правило, проверив, предварительно, что оно работает?

Наверное никак. Только внутри поставить какое-то условие и ничего не делать, если оно не выполняется.

я тоже сходу не нашел. получается надо уметь им пользоваться. Без отключений, проверок, включений слабо понимаю как его использовать. Если только хэллоу ворд писать циклически…

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

а есть пример? Мне кажется, это может быть интересно.