Сохранение значений тегов на сервере iRidium

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

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

последняя 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 у меня все работает нормально.

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

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

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

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

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

Добрый день)

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

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

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

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

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

я вошел в веб-панель управления сервера и открыл закладку 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 - штатное.

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

Купили эконом машину и обращаетесь к производителю ПРОШИВКИ ))) У меня вот когда бензин кончается, машина глохнет. А когда я бензин доливаю, почему то сама не заводится - вы там в прошивке сделайте таймер, чтобы каждые 10 секунд срабатывал стартер. Ему рекомендуют: поставьте специальный модуль автозапуска, а то стартер при таком режиме просто сдохнет и вы вообще останетесь без машины. Нет, мне виднее, говорит клиент, а вы просто т%%%е программисты, которые пытаются впарить мне ненужное железо...

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

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

Уважаемые Великие Разработчики!

Я сам такой-же как и Вы. Соблаговолите уделить немного вашего драгоценного времени.

При тестовом режиме и горячем перезапуске платы(прекращение подачи питания) значения сохраняются если до отключения подождать 1-3 минуты и не вносить изменения в теги которые сохраняются в базе.

После установки лицензии и в не тестовом режиме все в базе по нулям при такой итерации.

Мне надо решение сейчас. Летать за 3000 вёрст потом править нет желания. Решение с ИБП не подходит. система может быть обесточена на Большое время. Доступ к ней затруднителен. Интернета там нет. Планшет с которого управляется рядом с сервером лежит.

Спасибо Огромное если ответите.

Напишите в техподдерку и приложите свой проект (это будет приватное сообщение). Опишите, какие теги Вы хотите восстанавливать при старте.

1. Не сохранение тегов при перезагрузке - этого быть не должно. Выше выявили, что при штатной перезагрузке все в порядке, и теги слетают только при аварийной потере питания. Давайте разделим эти ситуации. У вас не сохраняется при штатном ребуте?

2. Извините, но Ваши ожидания обусловлены только этой ситуацией. Постоянная прямая запись на флешку - это замедление работы и гарантированный ускоренный выход флешки из строя. Для этого программисты используют кеш в памяти, чтобы запись шла блоками. В свое время LogicMachine в первых прошивках убивала прямой записью флешки за пару месяцев (!). Сервер, это не ПЛК с прямой записью в ячейки энергонезависимой памяти.  Поэтому по первому пункту обязательно сделаем гарантированное сохранение/чтение, но по второму - извините, я пока не вижу способа, не убивая флешку гарантировать сохранение тегов.

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

Проблема с сохранением данных на RPI по Persist подтвердилась. Постараемся исправить.

УРА!

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

Данная проблема была поправлена в версии 1.2.4

Подтверждаю. После перезагрузки командой sudo rebot теги сохраняются.
Но вот если обновить серверный проект из облака все слетает. Фидбеки принимают значения "0". 

Кстати, можете добавить настройку серверным фидбекам "значение по умолчанию"? У панельных проектов есть такой параметр для локальных виртуальных фидбеков. А то как-то странно при первой загрузке серверного проекта видеть нули в текстовых полях настроек панельного проекта. Приходится дополнительно инициализировать серверные фидбеки связанные с такими полями.

Ну или хотя бы дайте возможность указывать тип виртуальных фидбеков: целое число, дробное число или текст. И соотв. чтоб по умолчанию поля принимали значения 0, 0.00000 и "". А то видеть в текстовых полях по умолчанию "0.00000" для пользователей странно. Приходится городить огород в скриптах.

Добрый день!

Можно получить ответ на вопрос по значениям тегов по умолчанию?

И исправите ли сброс фидбеков после обновления проекта из облака?

Добрый день!

1. После обновления теги будут сбрасываться. т.к. место хранения - это сам проект (он затирается при загрузке нового).

2. "Значение по умолчанию" - неплохая идея (можно отправить на голосование), но пока что легче инициализировать в скриптах единым конструктором.

Александр, тут наверное был вопрос: "исправите ли вы сохранение значение тегов" после выхода новой версии и обновления её "через облако"... 

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

на версии 1.2.4 поправлен именно сброс при выключении/перезагрузке (параметр PERSIST).

Плохо что сам проект = место хранения.

Опять "приплыли" как говорится. Нужно что-то колхозить для хранения серверных (пользовательских) настроек. И время разработки и внедрения проекта опять затягивается((

Чтоб поставить на голосование лучше создать новую тему с соотв. предложением?

1. По месту хранения - посмотрим, насколько сложно утащить связи в пользовательскую БД (тогда не будет удаляться при перезаливке).

2. Там порешаем по хранению инициализирующего значения.

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

При тестировании проекта https://support.iridiummobile.net/communities/18/topics/21470-iridium-schedule-edit-server-client-project#comment-138847

выяснилось, что при Store In DB = String UTF8 запись значений происходит с некоторой задержкой,
т.е. если выключить сервер, то данные пропадут

1. Как это исправить?

2. Какое время записи в БД по умолчанию

на сервере (Win) настройки такие:

Добрый день.

Сохранение в системную БД через INSERT. Иридиум сервер обработает запрос с задержкой примерно 100 мс. После любой команды SQlite будет фиксировать транзакцию. В зависимости от настроек SQLite это ещё от 50 до 300 мс
(ожидая окончания записи данных на носитель). Если запрос выполняется через веб-интерфейс сервера (т. е. запись в фидбэк, который настроен на сохранение в системную БД), то отображение в веб-интерфейсе появится с округлением до 1 минуты (хотя запись в БД произойдёт как обычно). Если сервер не загружен другой работой (скриптами), то всё происходит относительно быстро. Если сервер не был завершён аварийно, то с корректным проектом (в котором нет явных ошибок) запись рано или поздно произойдёт.

Владимир,

проверил время двумя способами:

1. Открывал БД SQLite через некоторое время, смотрел таблицу данных на наличие новых строк в [STRING_TAG_HISTORY]

2. Создал триггер в SQLite с записью времени

CREATE TABLE `time_log` (
    `ID`    INTEGER NOT NULL UNIQUE,
    `TAG_ID`    INTEGER,
    `VALUE`    TEXT,
    `CRTIME`    TEXT,
    PRIMARY KEY(`ID`)
);

CREATE TRIGGER T_time_log AFTER INSERT ON STRING_TAG_HISTORY
BEGIN
INSERT INTO time_log(ID,TAG_ID,VALUE,CRTIME)
         VALUES(NEW.ID,NEW.TAG_ID,NEW.VALUE,datetime('now','localtime'));
END;

Время записи Store In DB [String UTF8] составляет порядка 40секунд.

Как повлиять на это значение?

При корректном завершении (Ctrl + C в консоли сервера) записи истории так же не происходит.

Добрый день.

Если сервер под Windows, то корректное завершение нужно делать в консоли двойным нажатием Esc.

По остальным вопросам ответим позже.

1. Удалил БД

2. Создал новый проект

3. Добавил комманду и фидбэк

4. Добавил примитивный скрипт

IR.SetGlobalListener(IR.EVENT_GLOBAL_TAG_CHANGE, function(in_sName, in_sValue) {

   IR.SetVariable("Server.Tags.Feedback 1", in_sValue); 
});
 
// subscribing for tag changes
IR.SubscribeTagChange("Server.Channels.Command 1");

5. Через веб-интерфейс вводил данные для Command 1, например числа или

[{"Name":"Blind open", "Start":1531909200, "End":1531923600, "Enabled":false, "Type":1, "RepeatEnd":0, "StartSunType":0}, {"Name":"Air conditioner switching", "Start":1532324760, "End":1532347200, "Enabled":true, "Type":0, "RepeatEnd":0, "StartSunType":0}]

Если добавить триггер в БД, то видно, что запись происходит раз в минуту

Добрый день.

Спасибо за предоставленную информацию.

Действительно, при выборе Store in DB = UTF-8 интервал составляет 1 минута (точнее не более 1 минуты). Однако выбор стратегии (по изменению значения или по интервалу) отсутствует в настройках студии (как старой, так и новой). После вашего обращения мы решили добавить возможность выбора стратегии сохранения в базу, но сроки реализации пока не определены. Мы сообщим вам по готовности.