[18098] Ошибка чтения текущих у ВКТ-9

ЛЕРС УЧЕТ: 3.67.4

БД: postgresql

Иногда при чтении текущих возникает ошибка, пример:

Ошибка сохранения данных для сеанса опроса 44813022. An error occurred while saving the entity changes. See the inner exception for details. 23505: повторяющееся значение ключа нарушает ограничение уникальности “PK_WaterConsumptionCurrent”

DETAIL: Detail redacted as it may contain sensitive data. Specify ‘Include Error Detail’ in the connection string to include this information.

Необработанная ошибка в сервере. Ошибка сохранения данных для сеанса опроса 44813022.. Разработчикам был отправлен отчет об ошибке. An error occurred while saving the entity changes. See the inner exception for details. 23505: повторяющееся значение ключа нарушает ограничение уникальности “PK_WaterConsumptionCurrent”

DETAIL: Detail redacted as it may contain sensitive data. Specify ‘Include Error Detail’ in the connection string to include this information.

В логах БД:

2026-10-09 03:01:11.440 +07 [1802579] lers@LERS ОШИБКА:  повторяющееся значение ключа нарушает ограничение уникальности "PK_WaterConsumptionCurrent"
2026-10-09 03:01:11.440 +07 [1802579] lers@LERS ПОДРОБНОСТИ:  Ключ "("MeasurePointId", "DataDate")=(1665, 2026-10-09 03:01:11)" уже существует.
2026-10-09 03:01:11.440 +07 [1802579] lers@LERS ОПЕРАТОР:  INSERT INTO public."WaterConsumptionCurrent" ("DataDate", "MeasurePointId", "BadValues", "CalculatedValues", "M_delta", "M_in", "M_out", "P_in", "P_out", "H_delta", "H_in", "H_out", "RawDataDate", "T_cw", "T_in", "T_indoor", "T_out", "T_outdoor", "V_delta", "V_in", "V_out")
        VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21)

Журнал:

Журнал опроса.xlsx (19,1 КБ)

Дамп:

dump._Общая очередь(26).2026-10-09.zip (5,0 КБ)

Проблема возникает очень редко (вероятно из-за того, что особо текущие и не читаются) и от чего зависит непонятно. Проблема существует довольно давно.

Это никак не связано с опросом ВКТ-9, так как ошибка возникает на уровне сохранения данных в БД, где данные обезличены.
Проблема возникала из-за того, что в одной из точек, по которым ведется опрос в представленном журнале, на момент попытки сохранения считанных текущих данных уже присутствует запись с меткой времени этих текущих.

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

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

Уточните, пожалуйста, ситуация всегда возникает по текущим данным как в приведенном примере? Или бывают случаи ее возникновения по архивным данным?
В целом она имеет всегда случайный характер или есть какие либо условия, при которых она воспроизводится стабильно?

Только по текущим (всегда PK_WaterConsumptionCurrent), что бы было по другим типам данных такого не помню. Стабильных условий выявить не удалось. Я придумал только два способа как воспроизвести ошибку, первый раз за разом мучать ручной опрос, а второй поставить на мониторинг и ждать. Тут как “повезет” может довольно быстро произойти ошибка, а может прийдется очень долго ждать.

Приложите, пожалуйста, расчетную формулу текущих данных, заданную в одной из точек. Также попробуйте провести опрос текущих только по 2-м точкам из 4-х: точки, в которой задана формула расчета, и точки, параметр которой участвует в этой формуле. Проверьте будет ли возникать такая ситуация при этом.

Также уточните есть ли у вас другие точки, у которых один прибор учета и при этом настроен расчет текущих по формуле, и возникает ли по ним такая ситуация?

Точка учета ХВС имеет следующие настройки:

Данные берутся с 7 доп. канала. P1 она берет по формуле с ГВС, то есть 1 тепловой ввод, 3 магистраль, формула просто берет значение без каких либо преобразований.

Проблема возникает на разных объектах. Те уведомления с ошибкой, что есть сейчас, там везде такая настройка. 100% утверждать, что проблема возникает только там где есть расчетные формулы не могу. Не анализировал я каждую ошибку, а уведомления я очищаю.

При опросе только двух точек учета проблема повторилась.

Вообще характер проблемы говорит о том, что ситуация не связана с прибором ВКТ-9, так как она возникает на этапе сохранения обезличенных данных. На всякий случай уточните у вас используются другие приборы учета помимо ВКТ-9, с аналогичной настройкой связанных с ними точек и возникает по ним подобная ситуация? Или по другим приборам попросту не возникало необходимости создавать расчетную формулу в одной из связанных с прибором точек?

Другие проборы есть, но только на ВКТ-9 используются формулы.

Я правильно понимаю, Сервер и СУБД установлены в Windows?

Нет, на Debian и сервер и БД.

То есть Сервер и СУБД внутри Docker-контейнера?

Они на одном сервере, сам ЛЭРС в контейнере, а СУБД нет.

Мы собрали тестовый стенд, в котором завели две точки учета Теплоснабжения (двухтрубная и однотрубная), привязали к ним “Имитатор теплосчетчика”, настроили в однотрубной точке расчетную формулу копирования P1 из двухтрубной точки, по аналогии с вашей формулой, после запускали ручной опрос текущих по обоим точкам очень много раз, но ошибка так и не воспроизвелась.
Пожалуйста, попробуйте у себя создать 2 такие же точки с “Имитатор теплосчетчика” и проверьте воспроизведется ли ситуация с ними у вас.

Не знал про имитаторы. Сделал 2 ТУ, но у имитатора нет доп. каналов, поэтому поставил на 2-ю магистраль для ХВС. При мониторинге на 9-м опросе произошла ошибка.

Может это конечно как то связано именно при использовании точки ХВС.

А попробуйте 2 точки Теплоснабжения, как описано выше. Сообщите будьте ли возникать описываемая ситуация при этом.

С 2 ТВС ошибка так же воспроизводится и с 2 ГВС тоже.

Ситуация еще более странная. Не понятно чем принципиально отличается ваша рабочая машина от нашей тестовой. Уточните, пожалуйста, какая версия PostgreSQL у вас установлена?

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

Какие либо специальные настройки самой Postgres производились или в целом данная СУБД была установлена “из коробки” и используется преимущественно с настройками по умолчанию?