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

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

RedRock выше от меня был уже график https://forum.gurtam.com/viewtopic.php? … 88#p162288
хотите для данной таблицы? Вот, мне не жалко

Дело в Виалоне.

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

Разложить его подпунктами для "Расход в движении" + "Расход на холостом ходу" не представляет труда математически для студента второго курса в рамках логики подсчета по входящим данным. Все нелепости с "разницей по дут между поездками" отсекаются параметром "минимальный слив/заправка", и не надо выдумывать ничего.

Если вы возьмете шланг и поедет проверять остаток топлива, то это будет единственное в статистике что у вас совпадет. Данные из таблицы поездок по суммированию на конец периода - не соответствуют реальности. Либо надо добавлять строку "Накопленная погрешность = хх", где хх будет равен "Расход "Расход в движении по поездкам + расход холостой ход в поездках" - (минус) "Расход по ДУТ". Но в этом случае цифры будут удручающие. Постоянно будут вопросы пользователей как и сейчас "Почему такая погрешность" или "Почему не совпадает".

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

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

Что этому мешает? )) Я выставляю пределе слив и заправка (допустим) по 19 литров. Т.е. пока топливо своими колебаниями не превысит мною заданный предел зачем эти колебания куда-то насчитывать поверх или отнимать? Для этого и задается количество литров, до объема которого все эти колебания никого не волнуют.

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

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

Я так понимаю вариант данных на скрине вас не устроил(Я надеюсь вы понимаете что колонку "Расход по ДУТ в движении" от виалона я специально поставил, в варианте клиента ее бы не было). И вы хотите увидеть какие то другие данные?
Напишите, что вам нужно в итоге, построить отчет или получить новый алгоритм расчета расхода движение под ваш случай.

Какой же это костыль?
Слой построений отчета и работа с ним - это костыль, а клепать 100500 алгоритмов расчета расхода топлива и выдавать пользователю множество опций для определения "какой алгоритм подойдет" - это базовый паттерн проектирования интерфейса, то есть "Чем сложнее тем точнее". Может начнем свой скрипты писать внутри интерфейса WH, прям 1С получится.

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

Тут то же самое потраченные усилия не стоют конечного результата.
Я прикрепил файлик, алгоритм который в вашем представлении должен решить вашу проблему, сработает для этой ТС?

Вы их видили с подобного тс, правда после фильтрации на EasyLogic.

По поводу подсчета пробега,  были случии когда потери шли на 2,3 сотни метров, а это кретично в отличии от 50 метров.

24Glonass Дело в том, что в "достаточно архаичной системы 2011-2013 года" проблема решалась тем способом которым ее решил я, замете из ходя из ваших постов в теме, где вы приводите простенькую формулу, а теперь реализация этой простенкой формулы вам не нравится, что вам нужно? Занять программистом гуртом бесполезной работой?

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

ПыСы: Вот и на Галилео при помощи EasyLogic мой фильтр работает при движении ТС, а при его покой ни какая фильтрация не нужна. На скрине разница обработанных и не обработанных данных, после примененного алгоритма уровень гуртомовской фильтрации снизился ни то в двое не то в трое. А разница между "всего потрачена" и "потрачено по ДУТ во время движения" снизилась со 100% до 20, что лишний раз говорит о том, что проблема в способе измерения расхода топлива, а не в алгоритмах его обработки.

24Glonass Решение есть на уровне формирования отчтета, но вы это называете фанатизмом и костылями, вместо этого требуя, проводить не аналитику ряда данных в момент движения, а выводить остаток после вычисления всего расхода и холостого хода, но виалон в отчете выдает данные рассчитанные за определенный период, в частности в расход топлива в движение попадут сообщения для обработки только те, в которых скорость не 0. Вот как раз в таком подходе сила виалона, а с другой стороны его слабость. И с таким подходом решить проблему расхода топлива во время движения НЕВОЗМОЖНО, потому что всегда будит расхождения. Но зато другие 99% функционала, при таком подходе, работают как надо и судя по объему рынка от такой концепции гуртом не откажется.
Собственно зачем отказываться, если не многочисленные проблемы системы могут решить интеграторы теми инструментами которые им предоставил гуртам: Калькуляция, API и расширения функционала за счет Apps.

Да и проблема детская.  Еше немного трёпа на тему "очень сложной задачи" и диалогов со сторонниками "решите сами калькуляторами", и я тупо скину данные за период движения по датчику зажигания, топлива и скорости в файл, и в таблице эксель приведу пример как Виалон это должен уметь опционально делать. Ну ей богу не доводите меня до такого порыва запозоривания Виалон Хостинг площадки...

RefRock, это точно будет работать Потому что мое заявление основано не на пустой теории. А на опыте вынесенном из работы с другой системой, где было много других частных случаев, и это работало хорошо.

Собственно тут и делема для нас с вами и ими, так или иначе ресурсы гуртома ограничены

Ограничены при 2 млн. пользователей настолько, чтобы не допилить базовый фукнционал? Нет тут никакой "Дилеммы" и не надо спихивать это на "Правильность установки дут" и пр. Не первый год в сфере услуг мониторинг работаем. ДУТ чувствительный инструмент и всегда буде присылать разницы, это и есть его правильная работа. А вот если вы его закошмарите настройками на приборе, вы потеряете часть данных которые могут вам пригодится для анализа. Поэтому решение всех вопросов по калькуляциям и алгоритмам должно решаться на стороне сервера.

Решать надо проблему площадке.