Математика расчета топлива в Wialon Pro

насколько понял проблема в тождестве формулы.

Данное тождество встречается исключительно редко, оно справедливо если есть идеальные данные по ДУТ, а это встречается крайне редко, в остальных случаях оно не гарантируется (подумаем над внесением в документацию этого момента с топливом)

Все эти расхождения есть следствия поведения ДУТ, которому свойственны скачки, эти неровности обычно прослеживаются на графике и в сообщениях, программе приходится учитывать их при подсчете топлива. Т.е. одно дело взять начальный с конечным уровни и заправки, как в вашей простейшей задаче и сравнении с яблоками, тогда потрачено по ДУТ есть некое значение, которое получилось если график расхода есть прямая линия (вернее их несколько, по одной на поездку, затем объект либо стоит либо заправляется). Но почти всегда на графике есть неровности особенно при перемещениях ТС, отчего значения прыгают - это естественное поведение датчиков такого типа, потому появляется погрешность при математическом расчете программой расхода топлива, ну и как следствие всей формулы.

+ в первом случае отчет всего за 4 дня а во втором за целый месяц, очевидно что за месяц разница вырастет больше

кстати а о каком ласт апдейте идет речь, с какой версии на какую?

Скиньте в личку сообщения и настройки. Заведу их на хостинг и сравню результаты с PRO.

P.S. разработчики PRO клянуться что изменения в алгоритмы не вносили.

Reference: VDI-78358-717
Reference: GZA-71988-828

Нет цены их клятвам)

В первоначальной реализации(PRO 1006) второй вариант рассчитывался как:
Уровень в начале интервала - Уровень в конце интервала + Сумма заправок
Но этот вариант был переделан по просьбе клиентов, поскольку имел ряд несовпадений с остальными рассчитываемыми данными отчета.
Причем эти несовпадения проявлялись на хороших и отличных графиках.

Минусы текущей реализации в том, что при среднего качества графиках(перепады данных в 10%-20% даже при фильтрации 10), суммирование заправок с разницей уровня не даст точных данных.
Что собственно наблюдается в Вашем случае.

Вы можете сделать запрос на возвращение старого метода PRO в качестве опции, но рекомендую попытаться улучшить показания ДУТ.
____________________________________________________________________________________________________________
Вы можете сделать запрос на возвращение старого метода PRO в качестве опции, но рекомендую попытаться улучшить показания ДУТ.
Еще раз для меня. Причем тут ДУТ? данные к вам заходят (вернее на Про) и А минус Б =С не получается.

Пишу здесь потому что не получаем в течении месяца вменяемого ответа.
Спасибо. Надеюсь на понимание.

Added after    9 minuts  18 seconds:
LeXXaT
Как хотите как нет. Но вы сами себе огромный минус сделали.
Приходим на тендер. Разрабы ПО, интеграторы и мы с нашим (вашим) Wialon.
Ставим, распаковываем, укатываем клиента. Отзывов куча. Все гуд.
А вот просто в отчете смотрят потрачено, заправлено и остаток. Ну не сходиться.
А я об стенку буду биться , вся команда селзов кружить но не сможет объяснить что за чудо алгоритм.

Зачем придумывать  и изобретать велосипед? Ведь ранее расчет работал.

LeXXaT, будем отстаивать  до конца?) ок.
Тогда по порядку еще раз:

1.babay
Вы недавно обновились с 1006 на 1301?
Мы очень давно обновляемся и обновились поэтапно и надеюсь что будем обновляться.
Опять же не корректно с вашей стороны говорить что вы там что то поменяли.
А как поменяли в тихую? без опроса, без предложений, без оповещения в блоге? Где это написано что бы можно было предъявлять нам.
Мол сами виноваты что не читали и тем более не знали.  Не хороший подход.

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

Каких клиентов? Которые взяли хостинг  подключили 2 машины к штатному датчику и спамили в  ТП? Что у кого дергается и падает уровень- Валидация вот ваша таблетка

Дальше.

Вот тут чуть не упал в когнитивный диссонанс

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

Пример сдачи топлива в полях заказчику. С контрольными замерами в сертифицированные мерники и сравнением в ПО.

Сливаем и заправляем топливо и разница в 0.5 литра до 2.1 что меньше 1-2%.
Мистика скажете Вы не может этого быть. Конечно не может. Годы работы и упорного труда.
Так что получается вообще не понятная ситуация. Даные ближе к идеалу а вот вас они не устраивают. Да и погрешность  вы почему то обещаете 15%)

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


Не работает.

А по поводу лодки

В конечном счете мы все в одной лодке, давайте решать проблемы обоюдно - вы предоставляете качественные данные, а мы предоставляем качественную аналитику

Предоставьте эту аналитику. И скажите нам чем вам помочь что бы она работала как заявлено.

Если стоит опция Расчет заправок без учета фильтрации, то уровень до и после заправки будет выводится по исходным данным, а при расчете Потрачено по ДУТ при опции фильтрации для уровня топлива учитывается фильтрация, и уровни соответственно будут отличаться (уровень исходного топлива, и уровень отфильтрованных значений), чем больше фильтрация, тем соответственно разница будет больше

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

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

Не поможет! Что за теоретические гадания?
Вы хоть раз видели его в глаза. Да и вопрос не в скачках, не в красоте датчика. А что бы в статистике данные сходились.
Пусть они кривые с разбежностью и т.д. вообще бред, кардиограмма. Но начало и конец, потрачено в результате суммировались и уходили в 0-ль. Скажем так.

Added after    3 minuts  44 seconds:
DmitriyChЯ не могу полностью убрать фильтрацию для ДУТ, так как изза условий эксплуатации ТС начнут появляться ложные заправки и сливы.
Уберите, все равно не поможет. Я бы тут не подымал вопрос если бы в тикетах пол года не "разводили воду".
Да и понимаю манера высказывания) "агрессивная" . Но и как клиента меня должны понять. Я своим не могу вразумительного ответа дать  и услышать от разработчика что мы занимаемся, мы делаем. Мы смотрим.
Нет ответа. Только датчики угла наклона) может быть помогут. Такие ответы взрывают 2 кабинета оваций от сотрудников и пол часа на перекуре разговоров.

Надеюсь на понимание.

Добавим для статистики от себя...
Берём спец технику - экскаватор Tarsus 888.
Бак очень специфический, техника постоянно перемещается.
1. Без фильтрации, "Потрачено по ДУТ 522 л", математически столбиком получается 526 (70нач - 59кон + 515запр)
2. С фильтром "2", "Потрачено по ДУТ 512 л", математически столбиком получается 513 (70нач - 57кон + 500запр)
3. С фильтром "5", всё сходиться литр в литр.
Период использовался с 1.08 по 29.08

[center]Без фильтрации[/center]

Дополнение. Проверил ещё на 5 машинах, погрешность в среднем 0,5% (интервал месяц, машины дальнобой, баки по 500-900л., фильтр 3). Получалось чем больше значение фильтра, тем меньше погрешность.

Хочется все-таки услышать ответ от Gurtam, когда все-таки сделают правильный расчет топлива учитывая фильтрацию ДУТ? Понизить фильтрацию не могу, так как появятся лишние заправки/сливы. Расчет заправок без учета фильтрации убрать также нельзя, так как тогда не верно будут рассчитываться заправки. Вариант только убрать фильтрацию и повысить уровни определения заправок/сливов до 30 литров, но тогда система не зафиксирует реальный слив.

По сути вариантов решения просто нету без вмешательства Gurtam

Penzyak ура 1.5. литра всего за один день) а сделайте  отчет 30 календарных дней  ( отчетный период для бухгалтерии )
и посмотрите результат ( заправок по  больше и не дай бог сливы)

Тогда увидите никакой разницы в хостинге и Про))). Говорю не первый месяц пытаемся сделать учет в подобающий вид)

П.С. Ну 1.5 литра  на обьеме 40-29( нижняя граница на графике) всего то..... умножим на х10 ( 400литров бак).
Результат будет соответствующий.

Я так понимаю, уже не только наша компания начала обращать внимание на данную проблему. Плюс к тому, проблема имеет место не только на Pro но и на Hosting. А представители Gurtam все молчат... Затишье перед бурей?:)