Повышение скорости и эффективности обмена со счетчиками

Добрый день!

ЛЭРС считывается данные со счетчиков крайне медленно и неэффективно.
По одному и тому же счетчику Меркурий 230 ART за один и тот же период с 01.10.2021 до
08.10.2021.
Меркурий Энергоучет затратил на чтение профиля мощности:
20:26:32 по 20:27:43 - менее минуты.
ЛЭРС с 20:08:15 по 20:17:53 - 10 минут.
Аналогичная ситуация со счетчиками ЦЭ6850М.
Чтобы пользоваться программой ЛЭРС необходимо обязательно настраивать автоопрос, т.к. потом вычитать данные за месяц просто не реально.
К том же расходы на связь значительно выросли.
При использовании Меркурий Энергоучет мы эти расходы не ощущали вообще.
Они составляли в пределах 500 руб ежемесячно.
Сейчас из-за ЛЭРС мы платим порядка 6000 руб./мес.
В версии 3.43 что-то сделано с эффективностью обмена?

С уважением, Алексей Кузнецов.

Алексей у нас к примеру кардинально противоположная ситуация в работе есть пару десятков 230 ART и нас убивает считывать данные штатным приложением по TCP/IP, идёт постоянный обрыв и.т.д и.т.п
Первое вы не описали детально:

  1. Используемый канал данных;
  2. Какие конкретно данные вы считываете.

Судя по тому как вы описываете ситуацию, вы используете CSD, относительно скорости, дело в объёме данных, я не исключаю два момента, настройка скорости в ЛЭРС учёт для прибора и объёма данных, не факт что штатным приложением вы вытягивали часовые данные.

Для примера эффективности опроса могу сказать что у нас закрытая сеть приборов насчитывает уже за 10.000 штук. Один из серверов ЛЭРС (клиента) справляется с опросом 800 приборов за 1,5 минуты каждые 30 минут, и стоит это всего на всего 30 рублей с прибора в месяц.

Штатное приложение это какое у Вас?
Меркурий энергоучет далеко не штатное считается.

Во вложении два протокола обмена из двух программ ЛЭРС и Меркурий энергоучет по одному и тому же счетчику запрашиваются одни и те же данные - профиль мощности получасовки.
Из протокола ЛЭРС видно, что каждая получасовка считывается отдельным запросом:
07.10.2021 20:08:46.897 Считаны значения профиля мощности за 01.10.2021 00:00:00 по ТП-789 яч.13
07.10.2021 20:08:48.411 Считаны значения профиля мощности за 01.10.2021 00:30:00 по ТП-789 яч.13
07.10.2021 20:08:49.937 Считаны значения профиля мощности за 01.10.2021 01:00:00 по ТП-789 яч.13

Из протокола Меркурий Энергоучет мы видим что одним запросам считывается пакет получасовок:
20:26:59.924 яч. 13: Запрос профиля мощности: 01.10.2021, 16, adr=039F
20:26:59.924 яч. 13: Запрос профиля мощности: 01.10.2021 8:00:00, 16, adr=03AF
20:26:59.924 яч. 13: Запрос профиля мощности: 01.10.2021 16:00:00, 16, adr=03BF
20:26:59.924 яч. 13: Запрос профиля мощности: 02.10.2021, 16, adr=03CF
20:26:59.924 яч. 13: Запрос профиля мощности: 02.10.2021 8:00:00, 16, adr=03DF
20:26:59.924 яч. 13: Запрос профиля мощности: 02.10.2021 16:00:00, 16, adr=03EF

Поэтому в настоящее время пользоваться ЛЭРСом для считывания получасовок профиля мощности практически не реально.
Журнал опроса lers 07102021.xlsx (24 KB)
Найди.log (3.38 KB)

Алексей если вы сможете объяснить для сравнительного тестирования как запустить ручной опрос в Меркурий Энергоучет я смогу это сделать без проблем. Мы увидим результат.
Автоматическое определение типа прибора работает.
Но сейчас я вижу такую картину как на скрине, масса не интуитивных окон. Не в обиду их разработчикам, но это трэш из кучит встроенных приложений, даже мануал не помогает, хотя это первое что я открыл…


Относительно загрузки данных через ЛЭРС, у меня без проблем месяц показаний в ручном режиме система вытянула за 10 минут пока я занимался своими делами.
Ручной опрос.xlsx (71.8 KB)

Не сочтите за высокомерие, но у меня к сожалению нет времени, а главное понимания для чего Вам запускать Меркурий Энергоучет.
Проблема с которой я обратился на форуме показана мной документально протоколами обмена.
Вы можете взять спецификации протоколов обмена к счетчикам Меркурий и Энергомера и там увидите, что есть возможность
пакетного считывания данных, которая в ЛЭРС не реализована.
Причем пакетно можно считывать не только профиль мощности, но и архив событий.
Вы Сергей не являетесь разработчиком или представителем ЛЭРС. А раз так, то от Вас скорее всего не будет зависеть реализация запрошенного мной функционала в ЛЭРС.
Так зачем же тогда мне Вас в чем-то убеждать и на это тратить время?
Протокол который вы приложили указывает, что обмен проходит не по мобильной связи CSD, а по TCP/IP. Задержки по CSD выше.
Вы в своем протоколе также видите, что одна получасовка = это один запрос. Пакетного считывания получасовок нет.
Затраченное время на считывание профиля мощности по 7-ми дням:
У меня ЛЭРС CSD 20:17:05.371 - 20:08:46.897 = 00:08:19
У меня МЭ CSD 20:27:36.410-20:26:59.924 = 00:00:37
У Вас TCP/IP 16:18:30.052-16:15:35.081 = 00:02:55
По-моему больше нечего комментировать.
Если бы я считывал месяц, то не трудно вычислить что это заняло бы не менее 33 мин на одном приборе. И это так и есть.
А будет-ли связь CSD устойчива в течении 33 мин. По нашему опытно далеко нет.
Добавляем сюда обрывы и перезапросы данных.
В итоге считать месячный архив с помощью ЛЭРС занятие мягко говоря для любителей.
Мы хотели перейти на использование ЛЭРС, но столкнулись с непреодолимыми трудностями.
Пойти чаек попить, к сожалению, для нас не подходящий вариант.
Пока что остаемся на МЭ.

Алексей, во первых ваш ответ не конструктивный, особенно всё что связанно с вашим наиценнейшем временем :du_ma_et: .
Проделанная мной работа по тестированию, значительно упростит задачи разработчиков.

Что вы описываете может упростит жизнь многим, включая меня.

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


В моих интересах развитие продукта, как для себя так и для всех участников рынка.

Что к чему? Что Вы от меня хотите?

Кузнецов А.Ю., правильно ли я вас понял, что вы хотите, что бы ЛЭРС УЧЁТ за один запрос считывал несколько записей суточного, месячного архивов и профиля мощности?
Если так, тогда предоставьте доступ к прибору и мы добавим такой функционал.

Если вы имели в виду, что-то другое, тогда опишите более подробнее, что вам требуется.

Так точно!
Если подробнее, то это требуется для счетчиков Меркурий (различные модели) и Энергомера.
За один запрос необходимо считывать не менее 8 часов получасовок. Можно больше, если позволяет протокол.
Архив событий тоже нужно читать пакетами.

Я предоставлю TCP/IP доступ для более удобной работы. Данные не публичные отправлю по почте

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

Мне не понятен подход к развитию ЛЭРС.
Вы добавите поддержку только для тех счетчиков к которым мы предоставим доступ?
Если мы приобретем счетчик новой модели, то опять столкнемся с этой проблемой.
Тогда не вижу смысла в доработке. В таком режиме пользоваться ЛЭРС-ом проблематично это хождение по граблям и потеря времени.
Я прошу принципиально проработать и изыскать решение для всех счетчиков Меркурий и Энергомера.
И решить вопрос так, чтобы в будущем не приходилось с такой проблемой сталкиваться с новыми моделями счетчиков.
На сайте https://www.incotexcom.ru/support/docs/protocol
в документации указано:
“1.5.4.2 Ответ с увеличенным полем данных
С целью ускорения передачи информации, представляющей собой архивы
упорядоченных данных (профиль мощности, журналы событий и т.д.), возможно чтение
данных в режиме длинных ответов. Максимальная длина поля ответа при таком запросе
может составлять до 255 байт как показано на рисунке 1.3.
Сетевой адрес Поле данных ответа CRC
1 байт 1…255 байт 2 байта
Рисунок 1.3 ? Структура фрейма ответа в режиме «длинных ответов»
Использование режима длинных ответов существенно ускоряет получение
запрашиваемых данных. Но возможна ситуация, когда внутренние процессы счетчика,
имеющие более высокий приоритет, могут нарушить передачу последовательности
фрейма ответа.”

Требуется для счетчиков Меркурий и Энергомера реализовать такой режим обмена.

У меркурия для 3-х фазных счётчиков единый протокол (Меркурий (Mercury) 203.2TD, 204, 208, 230, 231, 234, 236, 238)


Согласитесь могут быть неожиданности, которые лучше проверить.

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

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

То, что вы описали, не является одной проблемой, это особенность реализации драйвера конкретных моделей оборудования. Что бы устранить эту ситуацию, требуется внести изменения в код драйвера для каждой модели.

Вы привели выдержку из последнего описания протокола обмена. Драйвер для устройства Меркурий добавлялся очень давно, и в тот момент у приборов не было такой функции. А поскольку функции не было, то и добавить её мы не могли в систему.