Логика работы скриптов


#41

Секунды (зависит от объема исполняемого кода, конечно). А в таком варианте, когда устройство сначала создается в коде функции, а затем идет обращение к нему, кажется, что и задержек не надо. Или вы сталкивались с обратным?


#42

у меня иногда вылетали ошибки, вот я и страхуюсь. Нет опыта долгого анализа, хочу постраховаться. Хотя да, были ошибки. У меня движок ругался на незаполненные поля, хотя вирт девайс создавался до правил. Может, в mqtt в retained были хвосты… я не знаю, у меня нет возможности на ощуп находить решения. Они уже за годы эксплуатации должны быть наработаны, вот я и спрашиваю. Но, получается, мне надо использовать таймер, а с таймерами беда. Вот и ищу решение. Какой-то замкнутый круг.


#43

В качестве альтернативы движка правил, работающей на контроллере Wiren Board 6, некоторые пользователи используют node-red (открытый проект, изначально разработанный IBM). Там правила рисуются в виде диаграмм, и, по идее, не нужно писать и код.
Но это для вас очередной эксперимент будет.


#44

да я не против кода, наоборот, функциональное программирование стараюсь избегать. У меня тут проблемы не из-за кодинга, я не могу разобраться как 100% работать в движке. Вы сами соглашаетесь, что с таймерами беда. Если бы был этот 100% вариант, задокументированный, я бы им пользовался и был бы рад. У меня есть опыт работы в других средах, так вот теперь те, другие косяки я вспоминаю, как рай земной… А тут еще все осложняется сроками, на которые я попал для запуска проекта. Ни как не думал, что будут проблемы с базовыми вещами. Без таймеров не возможно сист. автоматизации создать. Вот и начинаются мытарства. Плюс работа с вирт девайсами, ошибки обращений, которые, наверное можно было бы обернуть в исключения, а не сваливать на пользователей… Хотел в начале писать код на ООП, бросил, сейчас переделываю все, - вот это да, проблема кодинга, наверное. Но зависоны от таймеров…