Сбой при опросе часовых архивов приборов учета тепла

Проблема 1.
При автоматическом опросе часовых архивов приборов учета тепла (ВЗЛЕТ ТСРВ-024М, 034, ВКТ-7) происходит сбой. Часовые архивы не считываются, либо считываются с большими пробелами. Кроме того, в режиме авто опроса периодически не считываются часовые параметры температуры. Как вариант решения этой проблемы пытались по новой переустановить дату с которой начинается авто опрос прибора. Данное действие давало временный результат. Через небольшой промежуток времени все начиналось по новому, часовые данные опять не считывались. Существует ли какое либо решение этого вопроса? :ne_vi_del:

Проблема 2.
С прибора учета тепла ВЗЛЕТ ТСРВ-034 (33) программным комплексом ЛЕРС Учет не можем считать базу настроек. Данная иконка в программе не активна. Поддерживает ли ЛЕРС такую функцию? Если поддерживает, как считать эти данные?

Проблема 3.
При опросе прибора учета тепла (ВЗЛЕТ ТСРВ-024М) в таблице интеграторов отсутствует часовой интегратор Теплопотребление (дельта Q). Как выполнить настройку для считывания данного интегратора?

У нас на форуме существует правило: один вопрос - одна тема. В данной теме будет обсуждаться только первый вопрос. По остальным двум вопросам создайте отдельные темы по каждому из них.

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

Хорошо, одна тема так одна. Тогда обсудим первую проблему. Повторю. При автоматическом опросе часовых архивов приборов учета тепла (ВЗЛЕТ ТСРВ-024М, 034, ВКТ-7) происходит сбой. Часовые архивы не считываются, либо считываются с большими пробелами. Кроме того, в режиме авто опроса периодически не считываются часовые параметры температуры. Как вариант решения этой проблемы пытались по новой переустановить дату с которой начинается авто опрос прибора. Данное действие давало временный результат. Через небольшой промежуток времени все начиналось по новому, часовые данные опять не считывались. Существует ли какое либо решение этого вопроса?
К этому добавлю, что для опроса прибора используется модем с сим картой имеющий статический IP адрес. Связь стабильна. Проверяли многократно. Потому что первая причина которую можно предположить - это перебои в связи. Но проблема оставалась. В режиме авто опроса часовые архивы считываются с пробелами (при этом суточные считываются без проблем) и их приходится до опрашивать в ручном режиме. Либо в часовых архивах отсутствует такой параметр как температура.

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

Например отчет часовых архивов одной из тепло систем прибора учета тепла ВЗЛЕТ ТСРВ-024М
Как видите с начала месяца в режиме авто опроса часовые архивы были считанны до 03.04.2019г 6 часов, затем исчезли показатели температуры. После 07.04.2019г. 23 часов опрос в авто режиме вообще прекратился. Если сейчас произвести опрос часовых архивных данных в ручном режиме, все будет нормально. Т.е. все необходимые данные будут вычитаны с прибора учета.

Котельная № 163 - Система отопления (закрытая схема) ТС2 ул. Энтузиастов 1А, Котельная № 163 с 01.04.2019 по 09.04.2019, Часовые.pdf (161 KB)

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

Сеансы опроса.xls (58.5 KB)
Журнал опроса.xls (23 KB)

В приложенном журнале опроса ни каких сбоев не отражено. Часовые данные успешно считались.
А вот в присланном журнале сеансов опроса отчетливо видно очень большое количество неуспешных опросов по причине обрыва связи, либо отсутствия ответа от коммуникационного оборудования. Об этом я говорил вам ранее:

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

Ошибка “Обрыв связи” никак не связана с чтением того или иного архива. Она возникает по причине плохого качества связи. Наиболее частое ее появление при опросе часовых данных обусловлено лишь тем, что часовых данных количественно больше чем суточных и на их считывание уходит больше времени. Поэтому регистрируется данная ошибка чаще при опросе часовых данных, чем суточных. Тот факт, что в приложенном вами журнале опроса отсутствуют сбои при чтении часовых данных лишь подтверждает это.
Обратитесь к вашему сотовому оператору для выяснения причин плохого качества связи в целом и возникновения ошибок обрыва связи в частности.

Ваш ответ на вопрос о некорректном опросе приборов по вине оператора связи, по сути, является «отпиской» не подкрепленной фактами.
Принцип пакетной передачи данных основан на «разрезании» массива цифровой информации на исходном устройстве на отдельные «порции» заранее оговоренной длины, каждая из них снабжается индивидуальным «заголовком». Такую «порцию» и называется пакетом.
В «заголовке» содержится информация о месте назначения (адрес, под которым компьютер пользователя, запросившего этот файл, числится в Интернете), об имени файла, к которому принадлежит этот пакет, и о порядковом номере данного пакета (то есть о том, из какого места данного файла он был «вырезан»), а также контрольная сумма - некое число, служащее для проверки правильности передачи.
Пакеты пересылаются по сети. В нашем случае используются два различных канала GPRS и Ethernet (по физическому проводу). На пользовательском устройстве, для каждого пакета после его получения подсчитывается отдельно друг от друга контрольная сумма и сверяется с тем значением, которое хранится в заголовке. Если два значения контрольной суммы совпадают, то пакет считается принятым без ошибок. В противном случае он повторно запрашивается с сервера (только этот пакет, а не весь файл целиком). Когда же все пакеты «в сборе», они автоматически объединяются в файл, являющийся точной копией исходного.
Соответственно, Ваше утверждение о виновности оператора сотовой связи не обоснованно. Ошибочно, заложив в алгоритм авто опроса игнорирование не прохождения части данных, можно также получить эту проблему на пользовательском устройстве. В нашем случае это сервер, где установлен программный комплекс ЛЭРС Учет. Это подтверждается тем, что при опросе по физическому проводу (Ethernet -канал) наблюдается аналогичная проблема.
Прилагаем журналы опроса приборов учета по GPRS и Ethernet -каналам.
Просим внести соответствующие корректировки в программное обеспечение ЛЕРС Учет для корректного автоопроса часовых данных.

Котельная № 101 - опрос по каналу Ethernet;
Котельная № 163 - опрос по каналу GPRS
Сеансы опроса.xls кот. 163.xls (40 KB)
Сеансы опроса.xls кот. 101.xls (42 KB)
Журнал опроса.xls кот. 163.xls (83.5 KB)
Журнал опроса.xls кот. 101.xls (62 KB)

В данном сообщении вы описываете протокол TCP. Соблюдение данного протокола обеспечивается транспортной подсистемой ОС. Любое приложение устанавливает подключение через транспортную подсистему ОС. ЛЭРС УЧЕТ здесь не исключение. Мы устанавливаем соединение через транспортную подсистему ОС, в которой уже реализован данный протокол. Мы не реализуем его самостоятельно. Поэтому ваше утверждение:

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