вообще, хорошо что много чего делают не программисты 
Все равно в той или иной степени это приходится учитывать.
Даже здесь на Wiki есть упоминание способа оценки изношенности памяти: EMMC flash storage wear level — Wiren Board
Пусть у нас используется память MLC объемом 4 Гб и каждый ее блок выдерживает 5000 перезаписей, а скорость записи у нас – 12 Мб/с.
Тогда, случайно заглючившей программе, генерирующей запись на максимальной скорости потребуется: 5000*3000/12 = 1250000 с = 20833 мин. = 347 ч. = 14 дней, что бы память достигла своего номинального предела изношенности.
Если у нас программа будет глючить по пол часа в день, тогда предел будет достигнут за 2 года.
Еще интересная статья на эту тему: http://www.cs.technion.ac.il/~dan/papers/fbrick-hotos-2017.pdf
вообще детали не интересуют, на рынке полно решений этой проблемы. А если она так остра, то производитель контроллера должен был сделать оборудование так, что бы память было легко заменить.
Вчера читал статью в которой обсуждалась тема retained значений под raspbery, там мужик писала что контроль за циклами сохранения блока этих переменных возложен на автора скрипта. Хочешь делай чаще, хочешь реже. Но разработчик все равно должен сделать функционал объявления этих переменных и обеспечить их хранение в области, которая может быть быстро скинута в флешпамять.
А как там работает железо, да пофиг. У меня давно был ваз 2106, это была последняя машина под капот которой я заглядывал.
Так и здесь есть решение этой проблемы – retain-значения. В wb-rules значения контролов виртуальных устройств хранятся в MQTT retained. В mosquitto настраиваются параметры сохранения значений.
В новом движке дополнительно сделали хранилище данных PersistentStorage, работающего поверх хранилища Bolt.
вы написали кучу текстов чтобы вернуться к тому, что я изначально уже писал?
мне не нравится хранить переменные программы в качестве значения виртуальных устройств. И я сейчас не буду тратить время на поиски, но вроде проскакивала информация от команды разработчиков с рекомендацией так не делать если цель получить их значения после рестарта, мол значения могут оказаться не такими какие ожидаете.
Давайте перестанем здесь это обсуждать. Тема создана для указаний на огрехи в документации или на сайте. Пока мне нравилось, что разработчики принимали репорты об ошибках и исправляли их.
Так это везде так, вообще-то. Это у всех производителей. Если я правильно понял, о чем могла писать поддержка.
Чудес-то не бывает, не по волшебству же значения сохраняются.
описание функций таймера:
Таймер становится доступным как timers.. При срабатывании таймера происходит просмотр правил, при этом timers..firing для этого таймера становится истинным на время этого просмотра.
но в описании нет когда свойство firing становится ложью. Так же и про функцию startTicker.
Я так понимаю ложью оно становится если вставлено в defineRule.
Но все равно не совсем понятна хронология событий.
Сработал таймер, firing = true, начался просмотр правил, просмотр закончился, firing = false.
Кстати, считаю что это плохая функция, которая только запутывает логику выполнения правил. Чтобы было все четко и логично правила должны выполняться по изменению каких-то входных данных, а не переодически по таймеру.
то есть свойство станет false даже если ни одно правило его не проверило?
Таймер штука очень полезная, есть процессы которые должны выполняться независимо от сигналов с устройств. Например включение котла, если через минуту температура на выходе не выросла, значит аларм.
Я сейчас испытываю как работает алгоритм который каждые десять минут анализирует историю (пока до пяти циклов истории) запуска и остановки котла с текущими температурами и изменение температуры помещения. Если она не меняется или не в ту сторону, подстраиваются глобальные параметры которые в следующее включения увеличат увеличат или уменьшат температуру нагрева или минимальную температуру остывания (что влияет на время которое отведено теплоносителю на отдачу тепла и частоту включения котла) прочее.
Что значит “не проверило”? Флаг станет false, когда цикл проверки закончится. Вообще я тут чисто теоретически рассуждаю, лучше написать простенький тестовый скрипт и посмотреть 
это тема скорее для логики работы скриптов.
мне не понятно, если я не обращусь к таймеру, флаг так и останется истина? А если нет, то ведь вполне вероятна ситуация, когда просто не успел его обработать.
Насколько я понимаю, все это работает таким образом.
В самом начале, в процедуре инициализации вызываются методы when и отслеживаются обращения к нужным свойствам системы. Готовится список переменных (свойств), от которых зависит значение функции when для конкретного правила.
В режиме работы отслеживается, если изменилось хотя бы одно свойство из ранее составленного списка, то вызывается функция when правила.
Таким образом, когда меняется значение timers.clickTimer.firing, это сразу приводит к проверке триггера активации правила: функции when. Таким образом, таймер пропустить не получится.
Однако, полагаю, конструкция типа timers.timer1.firing && timers.timer2.firing никогда работать не будет.
а если не создавать правила, мне просто надо знать, прошло 30 минут с момента когда я их засек.
Засекаете время: var startTime = new Date().getTime()
Когда нужно проверить, прошло ли 30 минут:
if(new Date().getTime() - startTime > 30*60*1000) {
// выполняем, что надо, если прошло 30 минут
} else {
// выполняем, что надо, когда 30 минут еще не прошло
}
а вот кстати, на вашем контроллере написано “Programmable Automation Controller”, а правильнее было бы “Freely programmable automation controller” или как там еще перевод фразы “Свободно программируемый контроллер автоматизации”.
-
В какой момент исполняется это код? Ежесекундно? каждую миллисекунду? По событию?
-
Чем занят контроллер пока ветвление не true?
В wb-rules сделан событийно-ориентированный подход, поэтому никак, кроме как по событию, код не исполняется. При этом, событие может генерировать и таймер, а не только поступающие данные с датчиков.
Между событиями идет ожидание следующего события.
Два объекта сдал. Супердоволен как проектировщик и монтажник АСУ. Очень практично все продумано и изготовлено, начиная с DIN-крепления, заканчивая несколькими каналами RS232 и гибкостью настройки любых параметров!
Один торговый комплекс на 2 этажа больше 1300м.кв., другой 1 этаж около 600м.кв.
а то, что у контроллера нет промышленных сертификатов (или как там называется) не помешало?
Достаточно декларации с проверкой на соответствие электромагнитной совместимости.
Прочие требования предъявляются по-моему только на спецприемках.