Устранение глобальной проблемы в калькуляции расхода топлива .

Еще раз повторю, "калькуляция" это "сбоку приделать", и по каждой машине сидеть "калькулировать", при этом все это начнет разваливаться как-только слегка изменятся условия эксплуатации транспорта.

Мне сегодня снова приходило обращение с просьбой "рассказать" что за муйня идет в "Расходе в движении" и почему она больше чем "Расход по ДУТ". Печально господа.

RedRock - сдается мне вы засланный "казачок" от программистов Виалона, которые хотят спокойно хлебать кофеек и ничего не делать. Уже три странице "топите" за какой-то сумеречный калькулятор и "фильтрацию на приборе".  У нас были такие программисты на старой системе в момент становления, но их потом выгнали и взяли новых. И те сразу сделали нормальное отображение топлива, заняло это 2-3 дня, и еще столько же на тест.

Так что про "правки в ядро". Да - нужны правки. у Виалона я уверен есть масса тестовых серверов, где правка двух строчек кода займет те-же пару дней с обкаткой.

RedRock с вами непродуктивно переписываться.
Вы не понимаете как работает текущий алгоритм и не пытаетесь понять.1

Нет. Не так. Берется уровень на начало (скорость 0) остановки и на начало движения (скорость не ноль), разница между ними считается в расход на ХХ. Берется тот же уровень на начало движения (скорость не 0) и уровень на начало следующей остановки (скорость 0), разница между ними считается в расход в движении. Что происходит во время самого движения никого не интересует.

Чем мне тут помогут валидаторы и произвольные датчики? В произвольных датчиках нет переменной, куда я могу суммировать дельту уровня, чтобы сделать аналог ДАРТ.  Да и сделать свой алгоритм исключительно средствами Wialon невозможно (только через API и свой велосипед).

Добавить калькулятор в отчет не решает проблему с часовыми расходами. Кроме того, у меня у каждого пользователя свой набор отчетов - каждому править? А если клиент сделает свою форму и выведет штатный столбец?

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

Вы про счетчики забыли, в котором можете указать валидатор, определяющий период движения. А дельта, например, время между сообщениями - это time-#time. То же самое вы можете указать в счетчике только вместо time ваш параметр ДУТ, там есть вариант с дифференциальным типом счетчика по параметру, но лично мне было не удобно с ним работать. Если вы суммируется весь ряд получившихся значений, вы в итоге получите дельта между последним и первым значением счетчика.

Ringo , конец периода "остановки" это одно сообщение, а начала периода движения другое сообщения и наоборот, вы с этим согласны?

нет.
Посмотрите на мой график в https://forum.gurtam.com/viewtopic.php? … 88#p162288

Лень сходить и посмотреть?

У меня на графике 8 остановок, для каждой всего 1 сообщение с нулевой скоростью, которое и является началом остановки. Соответственно начало движения (= ненулевая скорость) будет и концом остановки.
Или вы говорите, что конец движения (нулевая скорость) = началу остановки и одновременно = концу остановки? Тоже вариант, но сути это не меняет.

RedRock это у вас как-раз поди сглаживание в 50 выкручено, поэтому и начальный уровень разный получается.

Добрый день 24Glonass .

Да, действительно при скачках топлива во время небольших остановок может произойти ситуация с отрицательным расходом за интервал стоянки, который система игнорирует при построении статистики. Из-за этого сумма значений за х/х и за движение может не сойтись с общим значением потраченного по ДУТ. На самом деле корректнее проверять сходимость суммы с значением "потрачено по ДУТ в моточасах", но в любом случае проблемы неочевидного отображения для пользователя остаются.

Мы уже начали перерабатывать механизм обработки единичных интервалов таким образом, чтобы повысить сходимость сумм интервалов с общими значениями за интервал. Я был бы очень признателен если бы вы могли прислать несколько примеров ваших объектов и временные интервалы на которых проявляется проблема более явно.

Прошу прощения за долгий ответ и отсутствие реакции с нашей стороны в течение такого длительного периода времени.

pash, механизм обработки единичных интервалов, так же будит использовать отфильтрованные данные, и если так, то вы будите работать над тем, что бы при изменении периода отчета показания по уровню и расходу топлива не отличались.

24Glonass
В личные сообщения было бы удобнее всего. Да, примеры с данными за те же интервалы из других систепм было бы интересно увидеть на нескольких примерах.

Ещё вы написали в предыдущем сообщении, что "в данном примере самый частый случай, когда потрачено в сумме больше чем потрачено "По ДУТ" ". Такая ситуация возникает очень часто?
Проблема в том, что из-за колебаний во время стоянок там система определяет отрицательные расходы. И если за весь интервал построения отчета таких стоянок очень много, то именно так и происходит. Общее потрачено за интервалы хх отрицательное получается и если это отрицательное число сложить с "потрачено в м/ч в движении" то сумма сойдется, но мы не показываем отрицательных чисел там и выглядеть отрицательные числа будут не очень понятно.

Эта ситуация в моей практике 100% всего транспорта. Обратнызх случаев когда сумма движение + холостой ход, показали бы "меньше" общего потраченного по ДУТ я не помню. Если встречу, то сразу оповещу.

Собственно с ней  и началась моя "борьба" за  отображение в "Виалоне" чтобы стало корректно. С завтра начну засылать Виалон и как альтернативно отображет в л.с.

RedRock
Добрый день,

Расход на х/х не должен меняться если датчик правильно настроен. Собственно и сливы и расход считаются оба по отфильтрованным если в объекте не активирован расчет заправок/сливов по сырым данным.

Можете прислать мне в ЛС пример объекта со скачущим расходом на хх - постараемся выяснить в чем дело.