Групповой ручной опрос gprs-модемов, опрашиваемых по подключению, сейчас чаще всего бессмысленная операция. Если не настроен вызов модема в подключении, то ЛЭРС начинает опрос, не находит подключенного модема и на этом опрос заканчивается.
Далее речь о ЛЭРС LitePro.
Вызов модема через звонок работает крайне плохо. Использую усредненные данные для всех поколений модемов. Думаю тут много причин, тема не про это.
Т.е., повторюсь, сейчас получается групповой ручной опрос через gprs-модемы, опрашиваемых по подключению, сейчас почти всегда не возможен.
Предложение. При выполении ручного опроса через групповую операцию дожидаться подключения модема и только тогда опрашивать прибор учета.
Это не быстро. Но это лучше и быстрее, чем вручную “пинать” каждый модем или добавять это задание в автоопрос, а потом убирать из автопроса.
Что-то не совсем понимаю. Получается, что вызов у вас не настроен, только опрос по подключению.
Групповая операция опроса ставит модем в очередь на принудительный опрос. Соответственно, если модем не подключен, система пытается его вызвать. Но, как я понял, вызова у вас нет. Поэтому, система сразу завершает опрос с ошибокй.
Вы просите ждать подключения модема, но я никак не могу понять зачем это вообще нужно. Если опрос ведётся по подключению, система и так ждёт его подключения и сразу же начинает опрос. Если его нельзя “пнуть”, какой смысл опрашивать его вручную? Такая операция в принципе бесполезна, и я как-то не вижу смысла её оптимизировать.
Вы имеете ввиду настроенное расписание автоопроса “при подключении модема” ? Если да - то проблема в том, что есть модемы которые выходят только по расписанию, и его никак нельзя “пнуть” (например работающие от батареи). И иногда появляется необходимость снять определенные архивы за определенный период (часовые две недели назад). В таком случае поможет только редактирование расписания автоопроса (как и писал Kvashnin в начале темы), иначе нужные архивы никак не запросить. Это неудобно, и нет возможности запросить период “с - по”, только на глубину.
А сколько ждать такой модем? В системе есть жёсткое ограничение на продолжительность сеанса опроса, по умолчанию это 20 минут. Висеть и ждать подключения модема бесконечно тоже нельзя. Представьте, что он вовсе не подключится. Нам нужно будет в любом случае завершать принудительный сеанс.
В таком случае может быть рассмотреть вариант “одноразового” расписания автоопроса?
Т.е. мы хотим чтобы при следующем подключении с прибора были запрошены определенные данные, но чтобы это не влияло на уже имеющиеся расписание и сработало только один раз.
Потому что уже бывали случаи когда скажем нужно было с таких приборов снять часовые, изменялось расписание автоопроса и благополучно об этом все забывали, в итоге с устройства каждый сеанс запрашивались часовые, хотя они были нужны один раз.
Плюс ко всему при ситуации с необходимостью запроса часовых приходится сначала удалять имеющееся расписание и создавать новое, иначе не получится задать параметр “считывать с” - ужасно неудобно.
Неожиданный поворот, но предлагаемое решение - это must have для модемов с автономным питанием или вычислите с автономным питанием по моему единственно приемлемое, тут 7in прав. Я постоянно слышу фразу о поберечь батарейки ВКТ7 и не опрашивать у них часовые архивы.
Но я начал тему из-за LitePro. Принудительное подключение по CSD звонку не работает чаще всего. Как и писал, причин множество: версии модемов (обновлять версии никто не будет), плохая связь, ухудшение квалификации в телекоме и т.д. Но факт в том, что при текущей реализации группового ручного опроса, проблемой является то, что не опрашивается большая часть узлов. После такого ручного опроса нужен еще контроль наличия данных и снова групповой ручной опрос. Простая операция “съедает” много времени.
При этом опрос данных при подключении модема значительно стабильнее. Поэтому использование ближайшего/ближайших сеансов автоопроса для получения нужных данных из ручного опроса предпочтительнее создания ручного опроса по текущему алгоритму.
Механизм использования сеансов подключении модема может быть разный. Можно отодвигать планируемое задание, а можно использовать сеанс для получения данных и автоопроса и ручного опроса совместно.
Но важно учесть, что часто целью ручного опроса является получение часовых данных за большой период - недели/месяцы. Т.е. вполне может потребуется более одного сеанса связи с прибором. Нужен гарантированный способ получения данных из ручного опроса, чтобы избавить пользователя от трудоемкого контроля наличия данных
В подавляющем случае период подключения - 1 час. Запаса на подключение
2 часа должно хватить.
Хотя с учетом часовых данных и автономных приборов с периодом 1 сутки наверное стоит это оформить в виде
Т.е. задания на гарантированное получение четко определенного набора данных с приборов.
Вы описываете как раз автоматический опрос. Я могу понять “одноразовое” задание, которое обсуждалось изначально. Но если нужно контролировать данные, дозапрашивать, и т.д., это уже не ручной опрос, а автоматический.
Мне понравилось ““одноразовое” расписания автоопроса”, оно очень точно подходит для задач, из-за которых я создал тему.
При реализации моего предложения, все равно может возникнуть потребность контроля со стороны пользователя, т.к. за один опрос не удастся получить все данные. А т.к. у ПО будет задача провести опрос, а не получить данные, то пользователь будет вручную создавать групповые и просто ручные опросы.
При этом пользователю почти всегда нужно получить конкретные данные. Поэтому, на мой взгляд, стоит в ЛЭРС Учет создать возможность формировать задание “1 раз получить конкретные данные”.
Я не пойму критерий одноразовости. Если задание должно быть активным до того как будет считан заданный диапазон данных, его нельзя считать одноразовым. Теоретически, оно может висеть вечно. Например, если прибор зависает при выдаче архивных данных по какой-то дате. Это уже ближе к обычному, нормальному автоматическому опросу.
В любом случае, предложение из 1го поста в текущей системе, в принципе, возможно. То, к чему мы в итоге пришли, без предварительных работ нереализуемо.
Мы проведём аудит системы после выпуска релиза 3.49, чтобы понять принципиально возможно ли это.
