Есть идея, написать одно правило, которое бы выполнялось, скажем, десять раз в секунду и делало всё, что нам нужно так, как мы привыкли это делать в АСУТП. То есть, в нём мы будем работать с объектом dev.
Правильно ли я понимаю, что через dev мы обращаемся к копии состояния всех устройств (всех топиков) на момент вызова правила, и они не будут изменяться во время обработки правила?
Переменные, описанные через var, сохраняются между вызовами правила, но не сохраняются при перезапуске wb-rules или контроллера?
Как правильно запускать правило каждые 100 мс?
Что будет с производительностью (объект крупный)?
Добрый день.
Это довольно странное решение. JS - это все ж событийная модель, у меня нет опыта подобного использования.
Может, измениться, вполне.
Значение актуально именно на момент получения.
При перезапуске wb-rules (отдельно или вместе с контроллером) - да, не сохраняются, если не были специально помещены в хранилище.
Например GitHub - wirenboard/wb-rules: Rule engine for Wiren Board
У меня нет ответа, поскольку такого подхода не встречал.
JS - это все ж событийная модель, у меня нет опыта подобного использования.
JS вообще странная штука. Возможно, когда-нибудь я поразвлекаюсь с NodeRed, там хотя бы можно видеть цепочки связанных событий. Но, конечно, лучше выбирать проверенное решение.
Мне бы тоже было интересно, но 100мс я считаю слишком редкий вызов. Хотя бы с периодом 10 мс. Программа написанная на Си под линуксом для одноплатного компьютера слабее WB без проблем крутиться каждую 1 мс. Я понимаю, что тут ещё движок и язык более высокого уровня, но всё же было бы интересно узнать у разработчиков какое время можно считать оптимальным.
Сам по себе подход очень удобный на самом деле. Человек, который умеет программировать - напишет код в условно бесконечном цикле практически с любыми условиями (задержки, реакции на изменения и т.п.) гораздо проще и быстрее, чем это будут разрозненные узлы кода с событийным реагированием. Я тоже подумываю такой подход применить. Я умею программировать как для веб на js, php, так и на Си (для микроконтроллеров только), так вот навернуть код на Си в условиях сложных алгоритмов для меня проще и прозрачнее, чем согласовывать между собой разные узлы кода, каждый из которых вызывается в разных условиях и ситуациях. Но в тоже время я бы хотел для WB применить штатные средства программирования, а не создавать свои управляющие программы/драйвера на Си чтобы при обновлении, замене оборудования и пр. не нужно было вспоминать как где что куда прописывать, а просто переносить (мне или стороннему человеку) уже готовое правило в штатной среде самого контроллера.
Для подобного - на контроллер ставится специальный runtime. Да хотя бы Установка Rapid SCADA на контроллер Wiren Board — Wiren Board - просто как пример. И да, там миллисекунды.
Нет. Тот же таймер реалиизовать - как? Блокирующиий (не выйдет, JS не имеет в чистом виде delay)? Или опираться на системные время? Нет, получится слабочитаемое и неотлаживаемое. Ну, по крайней мере по моему мнению.
Как раз наоборот. Отдельный код под отдельную задачу, взаимодействие - через MQTT топики, через виртуальные устройства. Нагляднее, переносимее и каждый из компонентов независим.
1 лайк
Реализовать таймер то как раз самое простое. Но для реализации нужно понимать кратность адекватного и гарантированного вызова, время доступа к переменным и устройствам и т.п… Зная минимальный гарантированный интервал можно сделать счётчики на любые времена.
На остальные пункты я пока не стал отвечать, чтобы не тратить ваше время, ибо если данное решение будет занимать 90% процессорного времени, то и обсуждать бесполезно.
У меня нет данных про время запроса значений из топиков. Движок правил подписывается на их изменения и хранит текущие значения у себя в кэше.
Нет. Не получится хотя бы потому что функция может быть вызвана таймером второй раз несмотря на то что первый экземпляр еще не доработал. Можно, конечно, применить флаги блокировок - но это уменьшит надежность.
В общем - если требуется решение работающее циклом - то рекомендую использовать специально разработанное под него ПО.
1 лайк
Понятно, спасибо, да, этот момент про запуски я не знал. Но было бы конечно здорово, если бы вы добавили в правила возможность создания бесконечного цикла, по аналогии с потоками си, например. И я говорю именно про стандартное решение от производителя, а так то понятно, что на линуксе можно и на си написать, до вот только кто кроме меня будет об этом знать и понимать куда смотреть)))