Иногда ЛЭРС некорректно записывает данные (из-за проблем связи), из-за чего приходится вручную их выискивать и опрашивать заново. Есть скрипт который вылавливает явные косяки в данных и сообщает об этом, хотелось бы к этому скрипту прикрутить возможность самостоятельно отправить в ЛЭРС указание, какие дынные при следующем опросе добавочно нужно будет снять с перезаписью.
Было бы неплохо что бы была API, но и возможность задать это в клиенте приветствуется.
Вообще, если такие данные удалить, при следующем сеансе опроса они будут запрошены заново. Может, предоставить доступ к API для удаления потребления?
У меня тогда ряд вопросов:
- А какой диапазон дат проверяет ЛЭРС при опросе?
- На наличие проверяются все виды данных?
И еще различные мысли по теме. Иногда кривые данные отдает сам прибор и это не проблемы связи. В случае удаления мы будем получать одни и те же значения, а скрипт их опять будет удалять … и так по кругу. В случае с маркировкой данных можно будет выставить маркер, что данные были подтверждены повторным опросом. Можно сделать еще так, что если ЛЭРС считает данные недостоверными, при последующем опросе он повторно их прочитает и при полном совпадении выставит маркер, что они были подтверждены.
От даты постановки на автоопрос до текущей даты. Выбираются данные, которые ещё не сняты. В том числе, к таким относятся удалённые данные.
Не совсем понял. Если на автоопросе стоят суточные и часовые, они и будут проверяться.
Насколько я понимаю, это уже проблемы скрипта, а не ЛЭРС УЧЁТ. Может, описанные функции должен взять на себя именно он?
Я, честно говоря, пока не совсем понимаю что именно нужно маркировать. В исходном сообщении описано, что нужно промаркировать данные на повторный опрос. Я описал каким образом можно это сделать. Дальше вы описываете уже какие-то маркировки с подтверждением, но логика работы для меня неясна. Получается, вы хотите уже несколько дополнительных маркировок для каждой архивной записи?
Даже в отрыве от обсуждаемой здесь задачи возможность удалить данные через api будет полезна и во многих других случаях. Поэтому поддерживаю такой вариант
Цель: Решить проблему некорректных данных, что могут попадать в ЛЭРС.
Да, проверку можно реализовать и в скрите, но хотелось бы, что бы сторонних скриптов совсем не было. Не все же пользователи будут реализовывать анализ данных “на стороне”.
Вариант с удалением меня в целом устраивает, но не идеально.
Про маркировки. Отправная точка это тема [10161] Ручная настройка времени последних архивов. . Где указывалось, что данных нет в приборе. Тема с переопросом там тоже поднималась, но как то застопорилась. У меня задача как Вы понимаете немного другая, но решение я вижу в этом же ключе. Мне не нужно выбирать диапазоны с не существующими датами в БД, в моем случае данные уже сняты, но они пришли некорректные и ЛЭРС их записал. Далее на мой взгляд есть ручной вариант и автоматический:
- Ручной: Оператор просматривает данные (или внешнее ПО) и если его они не устраивают, выставляет атрибут “Переопросить” (понятно, что оператор может и ручным съёмом пройтись, но связи в данный момент может не быть и мало ли еще что). Автоопрос отрабатывает и если данные повторно пришли такие же, что и сейчас в БД, то выставляет атрибут “Подтвержденные”, а атрибут “Переопросить” снимет, иначе просто заменяет данные с снятием атрибута.
- Автоматический: По завершению автоопроса ЛЭРС в какой то момент анализирует данные и определяет, что данные недостоверны (вероятно по окончанию опроса, а может он это не делает, а только при отображение определяет достоверные они или нет, тут я точно не знаю). Пусть ЛЭРС эти же данные сам промаркирует атрибутом “Переопросить”, а дальше как при ручном варианте. На мой взгляд это существенно уменьшит “кривые” значения в БД.
Выскажу свое мнение по данной проблеме (возникает подобная ситуация с ТЭМ-104): считаю весь вышеописанный подход (скрипт, анализирующий данные; некие пометки в БД “переопросить/подтвержденные”) - неправильный, костыль если угодно. Тут получается что мы боремся с последствиями проблемы, а не с её причиной.
Думаю что все эти функции должны ложиться на драйвер опроса конкретного прибора. В том числе определение недостоверных значений, полученных от прибора. В таком случае не нужны будут никакие пометки “подтвержденные данные”, т.к. когда драйвер получит от прибора некую запись с некорректными значениями - он сразу же попытается их переопросить (как в случае, когда не сходится контрольная сумма пакета). Соответственно если после второй попытки опроса были получены такие же данные - значит они “подтвержденные”, и их можно записать в БД.
Вижу тут сразу несколько плюсов:
- Некорректные данные вообще никогда не попадут в БД, кроме тех случаев, когда реально содержатся в памяти прибора.
- Небольшая экономия трафика и сеансов опроса за счет попытки переопроса сразу же во время текущего сеанса, а не вручную оператором/скриптом.
- Не перегружаем интерфейс АРМ новым функционалом, не описываем как его использовать в руководстве пользователя.
Что касается доработки драйверов приборов - это безусловно отдельная тема, но я считаю что обсуждаемый в данной теме функционал не самое лучшее решение проблемы некорректных данных в БД.
У меня сложилось впечатление, что на всех приборах где связь нестабильна возможна такая проблема (у нас меркурии и ВКТ с такой проблемой часто встречаются). Согласен, что это костыль, и думаю многие с этим сталкиваются, а проблема до сих пор не решена, так может разработчики не могут ее решить? По этому и предлагаю такой вариант.
Во-первых, проблему всё-таки нужно решать в конкретных драйверах. Большинство устройств правильно опрашиваются при любых каналах связи. Возможно, стоит, как указал @7in решить вопрос с алгоритмом опроса в самом драйвере?
Вы создавали темы, в которых есть примеры таких некорректных данных по меркуриям и ВКТ-5? Если да, то дайте, пожалуйста, ссылки. Если нет, то покажите, пожалуйста, пример таких некорректных данных.
По моему мнению, практически все проблемы можно решить на уровне опроса. И если цена этого решения небольшая, лучше сделать именно так.
Проблематично найти с ходу, так как их у нас правят, особенно по воде. Вот пример по Меркурий 234 ART:
А можно ещё посмотреть сеансы опроса по этой точке за 23 и 24 августа?
К сожалению нет, они уже были удалены. Если найдем более близкую дату, то я выложу все данные.
Да, если найдёте, покажите, пожалуйста. Мы обсудим со специалистами по драйверам каким образом можно исключить такие проблемы.
Вы можете предоставить доступ к устройству, для тестирования вносимых изменений в драйвер устройства?
На данный момент мы пробрасываем на Streamlux Добавление поддержки расходомера Streamlux SLS-720F [10208]
Порт один на данный момент.
Мы добавили проверки, которые должны улучшить стабильность чтения архивов Меркурий 23x на плохих каналах связи.
Они будут доступны в 3.48. После выпуска проверьте, пожалуйста, возникают ли такие проблемы.
Если всё будет в порядке, мы будем добавлять такие же проверки в другие драйверы. Но по ним , пожалуйста, создайте новые темы. Так как доработки вносятся отдельно в каждый драйвер, нам нужно индивидуально проверять алгоритмы чтения.
Полностью проблема не решилась. И если и стало таких проблем меньше то не намного. Вот свежий пример:
zzz.zip (68,6 КБ)
Пожалуйста, создайте тему в разделе #lers-uchet:opros с подробным описанием. Специалисты изучат журналы и определят причины.