DmitriyCh пишет:По сути я и клиент хотят чтобы цифра в сводке по дням за каждый день сходилась математически (что Вы сделали видимо в ПРО версии), и итоговая сумма в сводке была равна числу в статистики.
В PRO этого не делали. Что делалось описано выше.
Дмитрий, загвоздка в том, что при дроблении данных ДУТ`а по произвольным интервалам(по дням, неделям...), и последующее их суммирование может не совпадать с рассчитанным по всем сообщениям. Вот пример:
Есть сообщения за 2 дня.
Объект ездит целый день. Вечером первого дня, контроллер засыпает и уровень топлива в последнем сообщении 90л.
Утром, при заводке машины уровень прыгает на 10 литров, и в первом сообщении уровень уже 100л. Далее уровень восстанавливается до 90л.
Имеем следующий график:
Заправка не детектируется т.к. объем мал.
Таким образом, потрачено:
1 день: V(начало 1 дня) - 90
2 день: 100 - V(конец 2 дня)
сумма: V(начало 1 дня) - 90 + 100 - V(конец 2 дня) = V(начало 1 дня) - V(конец 2 дня) + 10
Если считать по всему интервалу, то V(начало 1 дня) - V(конец 2 дня).
Итого расхождение в 10 литров. И это один из многих вариантов.
Intech Спасибо за идеи. Реализация похожих и стала причиной бурления в этой ветке 
1. Сделать разные коэффициенты фильтрации для заправок/сливов и для расхода, ведь когда заправка -машина стоит, и уровень условно достоверный, а когда движется появляются колебания и соответственно ложные сливы, приходится увеличивать коэффициент фильтрации, что влечет за собой увеличение погрешности заправок/сливов при при работе алгоритма....
Похожий алгоритм есть - интервал заправки(нач. и кон. сообщение) вычисляется по отфильтрованным данным, объем по не отфильтрованным.
Беда в том, что при раздельном вычислении объема заправки/слива/потраченного топлива не будет сходится их суммы с уровнем по графику.
P.S. Как писалось ранее алгоритмы будут пересмотрены, и подобные расхождения будут устранены.
P.P.S. Intech было бы интересно посотрудничать с вами в этой области
Alexander Adamovich
flespi
Хоть кто-нибудь бы ответил из представителей Gurtam
