Сейчас используя модем GPRS можно опрашивать либо по расписанию, либо по факту подключения модема. Первый вариант работает, только если есть устойчивая связь, второй работает и в случаях, когда связь плохая и модем подключается, когда может. При этом опрос по факту подключения модема имеет 2 огромных минуса:
ЛЭРС разрывает канал связи после опроса;
мы не управляем количеством опросов, и не редко ЛЭРС собирает больше данных чем нужно, увеличивая базу данных за счет ненужных текущих значений и лишних протоколов опроса.
Предложение: сделать гибридный режим или доработать текущие так, чтобы:
при неудачном опросе по расписанию подключения модема в течении 1 периода опроса использовались для 1 удачного опроса данных. После получения данных в текущем периоде чтение больше не должно производиться и все подключения модема должны игнорироваться;
для опроса по факту подключения модема это изменение тоже было бы полезно.
Вот пример, где бы это пригодилось. Модем примитивный и при пропадании канала связи снова пытается подключиться. Опрашивать нужно 1 раз в час. Ниже на картинках график подключения модема и график опросов.
Почему? В параметрах автоопроса по подключению есть настройка, где можно ограничить количество сеансов в сутки. Подключения модема после этого игнорируются и опросы не запускаются.
В примере выше видно, что ограничение количеством опросов в сутки не позволяет сделать график опросов оптимальным, т.е. опрашивать ровно столько раз, сколько нужно для пользователя.
Нет хорошего решения при имеющихся настройках в ПО, либо прибор будет опрашиваться через малые интервалы круглые сутки, если количество опросов сделать большим, либо только в первой половине дня, если уменьшить количество допустимых опросов
Думаю, что это не только проще, но и правильнее. Гораздо лучше решить задачу в существующих терминах и механизмах, а не придумывать новые. Переделки, которые для этого потребуются, гораздо меньше и делаются быстрее.
Насколько я помню сейчас при превышении количества сеансов опроса в сутки ЛЭРС начинает разрывать соединение с таким модемом. Это вынуждает большинство модемов подключаться снова и снова.
Если это действительно так - предлагаю при превышении количества сеансов опроса не разрывать соединение с модемом.
Это было сделано, поскольку постоянно висящее подключение потребляет ресурсы сервера. Если таких модемов хотя бы пара сотен, могут начаться проблемы. Менять это поведение мы пока не планируем.
Насколько я понимаю под GPRS модемом вы (как разработчики) скорее понимаете оборудование LERS LitePro или АССВ-030, которое имеет внутреннее расписание подключений к серверу.
Однако есть много и других устройств, например различные устройства производства USR IOT, которые как писал @Kvashnin:
Соответственно ограничение количества сеансов связи с таким оборудованием не применимо, поскольку при срабатывании ограничения у нас происходят тысячи переподключений одного устройства за сутки. Не думаю что постоянно висящее подключение потребляет больше ресурсов, нежели переподключающеся с интервалом 30 секунд.
Возможно стоит вынести эту настройку в расширенные параметры сервера?
Это другое предложение и обсуждать его нужно в своей теме. Здесь мы говорили именно о том, что невозможно ограничить количество сеансов в час, а не в сутки.
А зачем такие модемы ограничивать кол-вом сеансов? Если со связью в порядке, то они постоянно на связи и их можно опрашивать по расписанию.
Если же со связью периодические небольшие проблемы, то увеличение кол-во переопросов решает задачу получения данных.
Описанный мною случай - это ситуация, когда модем должен быть на связи, но подключается ситуационно, а на непредсказуемые периоды и нужно ловить моменты, когда модем подключился. Приходится использовать режим по подключению. И тут по правилам игры нужно задавать ограничения на количество сеансов. А далее выбор, либо задавать большое кол-во сеансов и вероятно в один из дней увидеть постоянно подключающийся модем по которому идет непрерывный опрос, либо данные получать только в первой части суток. Это слабо управляемая ситуация. И в этой теме я попросил больше рычагов влияния на ситуацию.
А в общем случае не вижу необходимости использовать с USR IOT режим запроса по подключению.
