"Похищенные моточасы". Ещё один малозаметный баг. Голосуем за устране

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

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

Тянуть до следующей точки надо лишь для верификации со стороны сервера,  что интервал работы оборудования полностью упрется в конец выбранного интервала пользователя.

А это разве не лечится параметрами интервалов в настройках таблицы?

Собственно последний пункт.
PS: проверил, оно походу на длительность не влияет. Только на Конец и Конечное положение.

24Glonass, добрый день!

Как и в ситуации с 59 секундами, сразу скажу, что это не баг. Такая логика системы, которая работала годами и не вызывала вопросов. Поч

Что касается самой ситуации: я могу согласится с тем, что было бы правильно проверять предыдущее (для начала) и следующее значение (для конца) и это бы позволило решить конкретную проблему с моточасами, но создало бы гораздо больше других проблем и вопросов.

Попробую все опасения разложить по пунктам:
1. Если следующее сообщение не пришло на момент построения отчета, то что делать? Эту ситуацию можно обойти, учитывая какие-то таймауты, но все же нюанс есть.
2. Что делать, если в следующем или предыдущем сообщениях нет показаний датчика? Искать дальше? Какое количество сообщений проверять или какое время должно анализироваться? Например, мы будем смотреть 10 минут, а сообщения приходят раз в 15 минут. Но и это можно как-то обойти.
3. Как позиционировать объекта на карте, если у нас нет данных в принципе в это время? Это небольшой, но все же важный момент.
4. Самый болюшой нюанс, который на текущий момент кладет потенциальную доработку в ящик, - это то, как определять другие показатели на этом интервале? Допустим, мы обрезали время моточасов не последним сообщением, а концом интервала. В конец нам нужно вывести значение конца. Какое время выводить? Если мы выведем конец интервала, равный концу отчетного периода, то и другие значения на интервале должны пересчитать. Например, пробег. Как нам посчитаеть его? Мы не знаем, какое значение пробега было в 18.30 (на вашем примере), поэтому посчитать правильно его не можем. А что делать с топливом и прочими значениями? Мы не можем моточасы посчитать одним способом, а остальные данные оставить нетронутыми.
Возможно, можно придумать, как рассчитывать эти данные так, чтобы всех устраивало, но сейчас мы заниматься этим не будем, потому что такой анализ потенциально может занять огромное количество времени (нужно пройтись по всем таблицам, т.к. логика везде должна быть одинакова), а результатов . Я бы оставляла этот вопрос на будущее, когда мы все-таки возьмемся за реализацию конструктора отчетов (надеюсь, что это случится).

Виалон может оперировать только теми данными, которые получает от трекеров. Додумывательство в данном случае - это искажение данных.

Что можно предложить:
1. Строить отчет точно по времени, т.е. до времени окончания моточасов.
2. Теоретически мы можем сделать доработку на бэкэнде, которая будет позволять расширять интервал отчета до следующего или предыдущего сообщения автоматически - сделать это опционально. Т.е. вам не нужно вручную искать значения и их выставлять. Но, скорее всего, если вы строите отчеты строго за заданный интервал (например, 18.30), то вам это не поможет.
3. Решать вопрос путем увеличения частоты отправки данных.
4. Работать так, как есть, и объяснить клиентам, что Виалон работает исключительно по данным, которые шлют приборы.

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

Если данных нет никаких совсем то Отчет и сейчас не строится. И это можно оставить как есть.

Ringo, 24Glonass, к сожалению, это не вариант все равно. Нельзя поменять моточасы, но не изменить расчет и вывод конечных значений.

Моточасы = Конец - Начало;
Конечные моточасы = Начальные моточасы (равны Конечным моточасам на предыдущем интервале) + Моточасы - это для ситуации, когда моточасы считаются по датчику зажигания).

Получается, что интервал моточасов будет меняться, а вместе с ним должны изменяться все показатели на интервале. А изменять мы их на текущий момент не можем по причинам, которые я описала в предыдущем ответе.

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

В вашем варианте изменяется не только время, но и сам интервал моточасов. Если меняется интервал, то и все остальные показатели изменятся.

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

24Glonass не совсем. Тут вопросы наличия этой точки и ее "задержки" от предыдущей.
>По сути ограничением можно считать допустим сутки.
Рили? Прибавить сутки ко интервалам, даже если точек нет? А если терминал "протерял" часть данных, в частности, отключение зажигания?

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