Your comments

скриншот интерфейса работающего в данный момент с сервером версии 1.1.8 и параметром №12:
шаг открытия вентиля примерно 30% на каждый градус разницы между текущей температурой и уставкой
Уверен абсолютно. Проект корректно показывал в процентах до обновления на версию 1.2. 

информация внизу страницы с загрузкой ЦП и памяти как-то отражает переполненность памяти или нагрузку процессора?


CPU: used 2.11%
Memory: used 157.75 Mb from 925.52 Mb (17%)
Storage: used 0.01 Gb from 14.66 Gb (0.09%)


при каких значениях можно считать что проект перегружает память? кроме перезагрузок что еще будет указывать на перегруженность? 


перепроверил еще раз с 11м. отобразились. но они не реагируют на изменения уставки температуры. т.е. не обновляются. как-будто из кеша статические значения взяты


Присмотрелся я внимательнее - а 11 параметр не уровень открытия показывает, а текущую температуру канала модуля.

я пробовал перебрать параметры от 9 до 15. Ни в одном не отображается уровень открытия вентиля в %.


наводя порядок - самое главное не сломать то что уже работает))

удалил иридиум, перезагрузил сервер. После этого он работал больше часа. Пока не перезагружался. 

В первом посте я писал что перезагружает его ватчдог иридиума. Т.к. после зависания иридиума, консоль на сервере работает какое-то время. 40-60 секунд примерно. 


позже загрузил на сервер проект. какое-то время работал. меньше 15 минут. потом начал перезагружаться. С различными интервалами опять же.

Закомментированная строчка убрала перезагрузку которая происходилка каждую 17ю минуту часа.  

Но кроме этого сервер перезагружается еще не понятно по какой причине. Не могу понять зависимость.


Сборка:


root@iRsrv-Han:/etc# cat /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/" 


1. Да, при sudo reboot. Не сохраняются теги и часть из них меняют значения на которые они никак не могут иметь. Т.е. ни в скриптах ни через интерфейс таких значений в теги не записываю.

2. В том и дело что нет постоянной записи. Запись в теги настроек приходит 1-2 раза в сутки или реже. Зачем менять настройки если все работает. Чтение более часто происходит. Но это не повод не сохранять настройки в постоянное место хранения.
В нашем случае система навигации даёт команду на сброс колес. Только не во время езды, как я написал, а сразу перед остановкой нашего авто. Потому что наверное считает что мы приехали и колеса нам больше не понадобятся. 
Кстати про возможность сброса кеша из скрипта была не моя идея. 
И про бензин вашу аналогию я не понял. Я описывал электро авто)) а вы про какуюту другую "машину". 

На текущий момент виртуальные переменные (теги) на сервере не сохраняются после перезагрузки. В моем случае даже если после изменения тега прошло много времени - час, или два часа. Т.е. получается что заявленное описание для параметра Persist не работает. Ещё я писал про случайные изменения тегов после перезагрузки, т.е. некоторые теги не то чтобы не сохраняются, но ещё и меняют свои значения как им вздумается. Это видимо тоже с особенностью работы кеша связано. Если продолжить аналогию то у меня в машине после остановки система навигации (бортовой комп) меняет назначения органов управления, и поворотники включают дальний свет, а педаль тормоза включает музыку.

И ваше решение с ИБП очень странное. Складывается впечатление что вы не знаете как сделать программно чтоб теги сохранялись.

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

ЗЫ
Напомню: сервер linux RPi3
iri server: 1.1.8

Навеяно, не могу не поделиться: купили мы в автосалоне новую, небольшую, эконом класса машину но с хорошей навигационной системой. Но через некоторое время у нее обнаружилась проблема - колеса отваливаются при езде. Все четыре. Ну что делать, ездить надо. Обратились в техподдержку автозавода. Там рекомендовали алгоритм: купите дополнительно автоплатформу (газель с трапом), поставьте на нее ваш автомобиль и ездите себе на здоровье. И на машине с автоплатформой безопаснее будет передвигаться - обзор дороги из машины гораздо лучше. Правда обслуживать придется две машины, но безопасность важнее же.



Заметил что ошибки с сообщениями "Crash detected" всегда происходят на 17 минуте каждого часа

В каждую 17 минуту запускается какой-то процесс. Не знаю за что он отвечает:


# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user<>command
17 *<-->* * *<->root    cd / && run-parts --report /etc/cron.hourly
25 6<-->* * *<->root<-->test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6<-->* * 7<->root<-->test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6<-->1 * *<->root<-->test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )


в /etc/cron.hourly:


#!/bin/sh
#
# Simple cron script - save the current clock periodically in case of
# a power failure or other crash if (command -v fake-hwclock >/dev/null 2>&1) ; then
  fake-hwclock save fi


закомментировал пока строчку эту. на 17й минуте сервер не перезагрузился