+2
Waiting for user's reply
AlexDr 2 months ago in Server Solutions / Linux Server • updated by nicks yesterday at 6:03 a.m. 40

Я создал на сервере (linux) канал и одноименный тег. При изменении канала значение, передаваемое в канал, сохраняется через вызов серверного скрипта (функция задана в Script Modiefer) в одноименном серверном теге:

function SaveChannelTagState(in_Type, in_Name, in_Value){
    IR.SetVariable("Server.Tags."+in_Name, in_Value);
}

На сервер значение тега меняется - видно через веб интерфейс.


В настройках тега установлены параметры 

  • Persist = Yes
  • Store in DB = Signed 32bit


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


Как это исправить? Надо чтоб значения тегов запоминались на сервере.

Answer

+1
Answer
Answered

Здравствуйте, 

Задача вошла в версию 1.1.7

Waiting for user's reply

Здравствуйте!


Какую версию сервера используете?


последняя 1.1.6

Вклинюсь, как обычно.

В настройках сервера есть параметр Insert Cache

http://support.iridiummobile.net/topics/12357-log-of-channels-and-feedbacks-in-ui/#comment-74324

Предположу, что ситуация с этим связана.


Странно, что сервер по временному тайм-ауту не записывает (commit) данные во время простоя.

Попробовал отключить Insert Cache - не помогло.

Сервер перезапускали? Свободного места достаточно?

конечно. я несколько раз перезагружал, проверяя настройки.

места свободно 14Гб примерно

Здравствуйте!


На сервере на Windows не удалось повторить проблему. Проверял вот этим проектом. Project 2.sirpz В нем всего два виртуальных канала, при измениении значения канала команды, это же значение записывается в виртуальный тэг, для которого выставлен флаг Persist.

Постараемся еще проверить на сервере на Linux. У вас просто десктопная версия Linux или это одна из платформ (UMC, RPI, NUC)?

Сервер на Raspberry Pi3, debian

В сервере на windows у меня все работает нормально.

+2
Under review

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

На какой срок выхода следующей сборки ориентироваться? Сдаю проект и тут такая досада...

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

Скорей всего связано с настройками базы данных какое время после изменения скидывать на диск данные.

Создал тестовый панельный проект, в котором привязал trigger button к свойству server/online и два поля: у пепрвого привязано к тегу на сервер свойство Text, у второго свойство Vaue. Как и должно быть в версии 1.1.6 текст отображается.
Тестовый проект: test feedbacks server tags.irpz
Тестовый проект в версии 1.1.6
То что отображается на сервер:


Удаляю на сервере iridium: sudo dpkg -r iridiumserverУстанавливаю версию 1.1.7: sudo dpkg -i /distrib/iridiumserver_1.1.7.....
Запускаю проект и наблюдаю эту картину:
На сервере:
Но стоит сделать в веб интерфейсе изменения канала, то он начинает отображаться в интерфейсе как и должен. Т.е. в версии 1.1.7 почему-то не происходит считывание канала при запуске панели.
После изменения канала в разделе Commands/Set на сервере:

Спасибо за информацию! Мы сделали некоторые изменения по данной проблеме. Но пока есть только сервер для Windows. Если на Windows у вас тоже повторялась данная проблема, то могу вам отправить последнюю тестовую сборку для проверки.

AlexDr via email 2 months ago
Для windows мне не актуально. Сервер под linux стоит на объекте, и надо чтоб он работал корректно.
+1
Answer
Answered

Здравствуйте, 

Задача вошла в версию 1.1.7

Добрый день)


Проверил - значения сохраняются.

Но иногда, при перезагрузке сервера, числовые значения серверных тегов произвольно меняют свое значение. Возможно серверный кеш неадекватно себя ведет. Зависимость понять не смог.

Это происходит только на сервере RasperryPi. В Windows все ок.

Waiting for user's reply

Здравствуйте,


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

я вошел в веб-панель управления сервера и открыл закладку Channels and feedbacks

есть два тега DayBeginHour и DayEndHour. исходные их значения были 6 и 0 соотв.

в панельном проекте изменил значения первого тега на 8

запустил обновление серверного проекта через трансфер

после обновления почему-то оба тега имели значение 8. 


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

до последнего обновления 1.1.7 - такие скачки значений тегов так же наблюдал периодически. с чем связано не понятно. в скриптах эти теги нигде не используются.

А можете скинуть панельный и серверный проекты нам на почту, либо закрытым сообщением? Попробуем сами повторить ваш путь.


Вы сказали, что заливали новый проект из Трансфера. Давайте попробуем локализовать проблему, кто виноват: клиент, сервер, студия или веб-интерфейс). Если вы сможете ответить на эти вопросы, было бы прекрасно (даже если точно не помните, пишите все):

1. А какие были в нем изменения по сравнению с тем, что уже был на сервере? Добавляли, например, новые каналы или фитбеки, переименовали текущие, или клонировали? Пытаюсь предположить, где они могли сработать внахлест друг на друга.

2. Может быть так, что проект серверный (новый) и панельный (вы же не обновляли там проект) являлись не синхронизированными? т.е. панельный управлял уже не тем набором команд и фитбеков?

3. В базе смотрели, в какое время во второй фитбек было записано значение 8? т.е. действительно ли он туда записался (логика сервера неправильно сработала) или просто отобразилось в веб-интерфейсе (глюк в веб-интерфейсе). Или вы не храните значения в базе для этих фитбеков?

Здравствуйте!


Актуален ли ваш вопрос? К сожалению, вы не ответили на вопросы моей коллеги, нам без этой информации будет сложно понять причину проблему. Тем более если проблема проявляется редко, то отловить ее буде проблематично. Кстати вы пробовали использовать новую версию 1.1.8 ? Наблюдается ли в ней аналогичная проблема?

Добрый день.


Вопрос актуален. К сожалению на объект попасть не могу, чтоб проверить все локально. Хозяева в отпуск уехали.


На вопросы постараюсь ответить исходя из того что успел протестировать ранее:

1. Проект разрабатывается больше года. Эти глюки со сменой значений серверных тегов наблюдал относительно давно. По времени они появились примерно после того как в студии версии 1.1.3 (примерно, могу ошибаться) я клонировал несколько серверных каналов. На протяжении разработки проекта различные каналы переименовывались. В т.ч. в драйверах устройств HDL.

2. Не может. Сервер и панельный проект обновлялись одновременно. К тому же глючат каналы давно созданные и добавленные на сервере.

3. Какие-то из глючащих тегов хранятся в базе, но не проверял их изменение по времени. Сейчас проверить не могу, т.к. нет доступа локально к серверу.


Сейчас на сервере стоит версия 1.1.8. После установки ее и обновления проекта скачки тегов так же замечал. Не описанных выше, других.

Добрый день,


Установлен iRidium Server 1.1.8 на Raspberry Pi 3. При "правильной" перезагрузке значения всех тегов сохраняются и при запуске сервера прекрасно восстанавливаются, но вот стоит ребутнуть Raspberry просто отключив питание - то тут как бог на душу положит, либо сохранит значения, что редкость, либо все значения переводит в нули. Как можно бороться с этой проблемой?

Поставьте простейший бесперебойник, чтобы RPi не ребуталась по питанию - проблему поборете самым правильным способом. Кроме проблем инициализации при каждом подобном ребуте Вы резко сокращаете жизнь SD-карточки, а в RPi это самый ненадежный компонент - "берегите его смолоду".

этот вариант не подходит. может кто знает как решить проблему?


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

Жаль, что не убедил, но предлагаю Вам задуматься о следующем: у RPi операции работы чтения/записи флешки являются "самыми дорогими", т.е. это узкое горлышко этого контроллера. Поэтому запись данных каждую секунду, как минимум "убьют" карту памяти, а как максимум Вы получите плату, обогревающую серверную, но не способную выполнять функции контроллера, т.к. постоянно будут лишь писаться теги в базу.


Александр, в нашем случае и большинстве проектов, с которыми нам приходилось сталкиваться, стоимость флешки и даже её замены с учётом выхода из строя несоизмеримы по затратам со стоимостью ИБП, в котором так же потребуется замена аккумулятора. А вот потеря простейших данных на ровном месте конечному заказчику кажется очень просто решаемой задачей, в прочем, как и нам: бери да пиши данные и файл и считывай. Сейчас любая операционная система даже при аварийном отключении питания может себя полноценно восстановить с последней или предпоследней точки. Если будет возможность варьирования количества записей или период записи - было бы прекрасно, либо уточнение каких либо условий (например запись через N секунд после последнего изменения но не позже чем через N минут после последней записи), что в свою очередь является неотъемлемой часть многих аналогичных вариантов.

Алексей, вынужден не согласиться с такой логикой. Т.к. сервер (контроллер) - это критически важный узел в автоматизации и потеря работоспособности флешки означает полный отказ узла, что повлечет за собой время на ручное (!) поднятие образа системы, авторизацию, лицензирование. Кроме того, это означает утерю всех накопленных данных. Ценность работоспособности + архив данных > стоимости UPS.

В принципе, мы сейчас обсуждаем проблему, которая является следствием нескольких ошибок, которые уже поправлены (осталась ошибка с нулевыми значениями при старте, и именно по ней и просим помощь, т.к. повторить не получается).
Следующий алгоритм представляется правильным и Вашу проблему он вполне решает:
1. Для persist тегов данные хранятся в кеше (оперативной памяти).
2. Вводим параметр Persist_time со значениями [OnStart (по умолчанию), 1..3600 min]. С данной периодичностью данные будут сохраняться в БД (перезатирать предыдущие значения).
3. При старте данные берутся из дампа кеша (если работа завершилась корректно), а если там нет значения, то из БД (если был ребут), иначе выставляется 0.

Я так понимаю, что этот механизм всех устроит??

Не такая уж флеш и убиваемая.

я в своих контроллерах отсчитываю время после последнего изменения и произвожу запись с контролем crc и не чаще определенного времени. Если crc не совпадает откатываюсь на пред блок с верным crc. И ещё ни разу флеш не билась. А в посл версиях ёмкость большая стоит обеспечевающая время для записи. При снижении напряжения по АЦП производится запись из рам а Флэш. Это более правильное решение чем ups. ТК время на которое пропало питание неизвестно. Чуть позже попробую ваше решение что вы описали . Спасибо.

все перепробовал. и по значению и по времени и персист ес но. раньше вроде сохранялось, иногда сбивалось. а сейчас совсем не сохраняется. грешу на переход на новую версию. 15го уже вылет в хреново кукуево. кто чем может подскажите. летать за свой счет на объект нет желания.

1. я так понимаю persist - это флажок показывает что значение надо писать в БД. и как его сохранять.

2. не понял что вы хотели сказать.

мне надо чтобы при внезапном  выключении восстанавливались значения которые были хотя бы 20 минут назад. Но этого не происходит.

только при корректном завершении сохраняются. а делее если опять неверно завершили то опять каша в базе.

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


Вы можете "накостылить" JS, который при старте будет делать запрос последних значений из БД и выставлять их.

Не оставляя надежду: бытовые ИБП стоят 2 т.р....

ИБП не решит проблему(время без питания может быть сезон). это надо подавать сигнал еще о пропаже напряжения и сворачивать работу приложения.

На удивление но сегодня с утра случилось чудо.

В проекте была переменная которая часто менялась с коротким периодом времени.

В итоге менеджер БД который управляет сохранением ее, видимо сбрасывал значение таймера и начинал отсчет времени заново и не производил запись. Как только я это значение убрал из записи в бд. то другие значения сохранились после некоторого простоя после последнего изменения. Меня удивляет другое почему этих важных параметров не вывели в веб интерфейс и вообще нет описания параметров вебморды. У вас же серверное устройство и должна быть гарантия сохранения параметров.

Здорово если сделают flush команду из скрипта сброса базы на диск. Печально что нет команд работы с файлами.

Если бы дело было в 2р.


А как корректно завершить работу сервера чтоб значения записывались? 

sudo reboot - это нештатное завершение для сервера иридиум?

sudo reboot как раз является корректным завершением, и.к. он перед перезагрузкой даёт команды на закрытие всех приложений, в том числе и иридиум и даёт им возможность слишь кеш в основную память... Только перезагрузка по питанию играет злую шутку с данными, хоть и не всегда...

Вот в моем случае значения слетают в 0 при перезагрузке по sudo reboot

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

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

так никуда не годится.

проверти как часто пишутся данные в базу.

нужна пауза в изменениях тегов минуты 2-3 тогда база запишется на диск. в общем костыль.

sudo reboot - штатное.

Значения изменяются очень редко. А вот при горячем перезапуске значения слетают к черту часто. И флешкин ресурс тут ни причем.  Если бы была возможность работать с файлами из под скрипта то проблема решилась банальным чтением и записью в файл. Наверняка есть какие-то параметры базы данных году указываются времена сколько ожидать транзакцию обращения к бд а после сохранять ее. И пр настройки. Ведь проблема очевидна. Как ее решить?


Ну что нет решения совсем сохранить 20 байт данный и восстановить. что колхозить все через экзешник с командной строкой. а ну а прочитать никак.