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


#1

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

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

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


#2

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


#3

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

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


#4

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

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

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

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


#5

WatchDog.txt (3.4 КБ)


#6

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

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

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

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


#7

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


#8

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

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


#9

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

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

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


#10

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


#11

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


#12

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


#13

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

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


#14

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


#15

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


#16

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


#17

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


#18

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


#19

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