[Закрыто] Датчики после обновления

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

upd:

последние правки внесены.

Если был создан ДУТ, но не было датчика зажигания (т.е. расход по расчету стало брать неоткуда) - создан датчик зажигания, расход на х/х соответствует предыдущим настройкам, параметр выбран speed, но мы все-же рекомендуем использовать настоящее зажигание или заменить его на const1 (эмулируя постоянное включение)

Расход по расчету и нормам (если ранее датчики зажигания отсутствовали) добавлен в такие объекты.

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

"Хорошо бы у этих датчиков новых таблицу пар XY заполнить автоматом. Что-то подсказывает, что так будет проще объяснить происходящее." - на данный момент работы проведены, но примеры ее заполнения и расчета даны в этой же теме ранее. Если у вас остались вопросы - напишите на serd@gurtam.com имя объекта и я обязательно поясню на именно этом примере откуда и что получилось.

Давайте по порядку

"А то ведь раньше у пользователя было два раздела, куда он вбивал данные из паспорта, и получал две колонки в дополнение к показаним ДУТ." - зима это повышенный расход. т.е. на сколько % больше тратит объект, когда условия специфические. Как показывает практика - там либо использовался дефолт и нормы не были активированы, либо нормы использовались "показать на всякий случай". Если вы действительно хотите учесть сезонность - достаточно исправить расчет в датчике. Например по аналогии с 20% - в таблице для зимы значение датчика будет 1,2 - для лета 1. Тогда весь расход будет умножен на повышающую норму в нужный период.

"А теперь как? Колонка расчёта одна." - существуют варианты, как и ранее
- создать зажигание и писать норму туда
- создать ДПНД и писать норму туда
- фильтровать вывод данных в отчете по нужным датчикам

"Куча вопросов. Суммируются ли датчики?" - да, и зажигание и коэффициенты суммируются.
"А если надо порознь?" - см. выше. Также могу помочь получить цифры и на примерах - адрес тот же - serd@gurtam.com или support@gurtam.com
"Сколько отчётов надо создать, для каждого датчика?" - в зависимости от потребностей пользователя. Как писал Максим выше - как правило лучше дать одну итоговую цифру, а все остальное скрыть.
"Где указывать какой?" - маски или датчик моточасов - в зависимости от того, что используете.

Выходные удались на славу?
Мне одному кажется, что разработчики пытаются сделать из нас программистов. которые вещи простые видят в двоичном виде?
Объясните, например - нафига мне (как конечному клиенту) считать какой 1 марта по счету день? Или на стенку календарь лепить от 1 до 365 с пояснениями где и как?
Второе - как мне теперь клиентам конечным давать доступ к датчикам и как объяснять зачем создавать и редактировать какие то датчики?
третье - где теперь в отчете искать датчик потраченного по нормам? Раздел "Потрачено по расчету" такую х/**ю пишет, что  легковой автомобиль превратился в карьерный самосвал по расходу топлива. Если раньше машина кушала как должна, то теперь по отчету жрет как будто на ней по 100 т везу по ухабинам?
Вот объясните, как и нафига? Вот реально появляется желание сравнить с немцами в 41 - не предупредив и не сказав о последствиях.
Если раньше клиенты сами считали расходы и прочее - теперь сижу за них делаю, поскольку реально не возможно объяснить тетеньке, что 60 день день года - это 1 марта, поскольку она меня просит тогда туда календарик воткнуть. Делаю за них, поскольку водители сидят и ждут ЗП, расчитанную по пробегам и нормам. Офигенно сделали просто, слов нету!!!
Где искать в отчете потрачено по нормам?????

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

"им не подходит неинформативность документации, невозможность рассчитать три математических операции (умножение, деление, снова деление) или то, что система "изменилась", но их не спросили?" - все верно - Вы прям с языка сорвали. Зачем лишний раз делать какие-то дополнительные расчеты? Зачем снова переучиваться, причем на ошибках, которые не откатали? За чьи деньги?

"как раз данное обновление было направлено на то, чтобы сделать работу алгоритма как можно более простой и понятной. По примеру - вот расход на х/х, вот состояние, когда тратится больше (например объект поехал) - получите результат. Максимально просто и ясно" - то есть сделать три дополнительных расчета (умножение, деление, снова деление) - это и есть более простой и понятный алгоритм? Помнится долго просили сделать настройку расход на х/х в л/ч. Дождались, но не такой же ценой. Объясните теперь - если не известен расход на х/х. Простой пример - не учитывается холостой ход. Ставим 0 и в результате получаем 0.

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

"опять же, развитие системы идет своим чередом и Wialon Hosting постоянно обрастает новым функционалом. Ровно это и произошло тут." - правильно выразились - "обрастает", но не функционалом, а алгоритмами и логиками

"нет, мы не стремимся сделать из вас разработчиков ПО, наоборот - наша задача дать вам такой инструмент, который подойдет к максимально возможному количеству вариантов использования." - тогда верните календарь для определения лета и зимы!!!

"это вовсе не обязательно. Как правило зима - это всего-лишь + какой-то процент к расходу. Сама зима - 90 дней (или около того). Разделить год на номера дней по месяцам - например 1 декабря это примерно 335 день (365-30), а первое марта - 60-й (1+30+28) на наш взгляд не так сложно. Тем более, что точности тут и не требуется - настройки, отличные от дефолтных, применялись в менее 1% от общего числа объектов. А вот то, что в Wialon исторически использовалось под названием нормы - это по сути такой-же расход по расчету, только немного другой. И это неверно, путает человека, не учитывая того смысла, который в этом был." - здорово, теперь идем путем вычисления! Если все человечество идет путем оптимизации затрат и упрощения - вам же ничего сложного высчитывать 153 день от начала года. Мне допустим потребовалось секунд 30, чтоб подсчитать в уме точно и без ошибочно. Нафига тратить 30 секунд, если можно оставить календарь???

"доступ к вкладке "расход топлива" напрямую влиял на работу и поведение алгоритма в отчетах. Теперь этот доступ клиентам можно закрыть, дав доступ в другое место. Большинство датчиков (расчета) будут вести себя абсолютно одинаково, а значит их можно импортировать, создав один раз. Объяснив простую методику расчета - получите людей, способных отредактировать самостоятельно поведение объекта любым необходимым образом." - и получим дополнительную головную боль при редактировании не умными и не осведомленными людьми.
"теперь графа одна - расход по расчету." - только почему то отличается значение "расход по расчету" во вкладках "поездки", "сводка" и статистика. Кому верить?

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

" настроим вам циферку." - за помощь по почте спасибо, но все уперлось в расход на х/х. А он не нужен!!! Понимаете - НЕ НУЖЕН. Ставим 0 или 0.1 и весь расчет идет к 0.

Забыл пояснить - может кому то интересно будет. Отсутствие х/х обусловлено тем, что машины по найму. в договоре не учитывается никакой х/х. Оплата строго по пройденном пути. Хоть ты пешком груз неси, хоть на велосипеде, лишь бы трекер был на связи и рисовал траекторию перемещения. Зачем в такой ситуации х/х учитывать? Это думаю, логично. Если надо учитывать - заполняем поле или включаем галочку, теперь же приходится многим предоставлять доступ к настройкам датчика, объяснять как делать и рассказывать логику работы алгоритма. Куда ж проще то?
Простой пример. Ставим в настройках х/х 9 л. Машина 4с лишним часа простояла и проехала 150 км. В пробеге расход по расчету - 1,5*9=13,5л. А зачем в статистику ставится сумма и простоя машины за 4 с лишним часа? Сделайте тогда в статистике расход по расчету в поездках. Именно в статистике.

Баталии не утихают, поэтому отвечу всем и по порядку.

SibNaviCom

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

"то есть сделать три дополнительных расчета (умножение, деление, снова деление) - это и есть более простой и понятный алгоритм? Помнится долго просили сделать настройку расход на х/х в л/ч. Дождались, но не такой же ценой. Объясните теперь - если не известен расход на х/х. Простой пример - не учитывается холостой ход. Ставим 0 и в результате получаем 0." - если зажигания нет, создайте датчик с параметром const1 и оно будет активировано всегда. В предыдущей итерации алгоритма расчет был 0 итак - тут нужно определиться, чего именно нужно пользователю.

"то есть эти функции по расчетам перенести на них?" - нет, просто предлагаю не утрировать и не относиться к пользователям, как к детям. Все-таки ситуации разные, а при должном объяснении все становится понятно и просто.

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

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

Адрес почты, напомню, прежний - serd@gurtam.com

"здорово, теперь идем путем вычисления! Если все человечество идет путем оптимизации затрат и упрощения - вам же ничего сложного высчитывать 153 день от начала года. Мне допустим потребовалось секунд 30, чтоб подсчитать в уме точно и без ошибочно. Нафига тратить 30 секунд, если можно оставить календарь???" - 153 день это вы так про первое мая? А к чему такая точность, если можно взять 150?

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

"только почему то отличается значение "расход по расчету" во вкладках "поездки", "сводка" и статистика. Кому верить?" - верить можно только себе. В вашем случае у объекта длительные интервалы х/х - отсюда и повышенный расход. Поэтому из основных правил - посмотрите, какая из цифр лучше отображает картину и используйте только нее. Как - написал вам на почту.

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

"за помощь по почте спасибо, но все уперлось в расход на х/х. А он не нужен!!! Понимаете - НЕ НУЖЕН. Ставим 0 или 0.1 и весь расчет идет к 0." - тут немного выше написал про эмуляцию всегда включенного зажигания. Если х/х вообще не нужен - создайте зажигание как делалось для состояния "по умолчанию" (т.е. на параметр speed) и х/х у вас не останется вовсе. Опять же - если будет новый объект - пришлите на почту и покажу, как именно.

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

"Второй минус - ушел клиент , хоть и не большой (18 объектов), но старый и надежный. Причина - "ты не можешь сделать так, как было и не слушаешь что тебе говорят". Зато обрадовались из Новосиба операторы - через час объекты с историей перенесли на ПРО, где такого нет. Это ОГРОМНЫЙ минус." - немного выше писал, но на всякий случай повторюсь - цифру, о которой вы говорите вернем. Обязательно сделав ее более универсальной, обязательно добавив возможностей. Я, конечно, понимаю, что сейчас снова пойдут в ход аргументы, что "лучше оставьте хотябы все как есть сейчас", но система обязана меняться.

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

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

"Как раньше было - ввел имей, создал зажигание по напряжению, проверил корректность - все... стабильно и четко работало. А щас еще и расчетами надо заниматься, умножать, делить, вычитать. И это , б****, за наши же деньги!!! АУ!!!!" - Нам наступают на пятки конкуренты, а партнерское сообщество давно говорит, что механизм топлива несовершенен. Его улучшение и забота о том, чтобы вы смогли дать решение с помощью Wialon для любой ситуации - наша прямая обязанность. Застой в этом механизме итак обошелся (в том числе наверняка и вам) недополученной прибылью. Я при общении с партнерами часто слышал, что приходится клиентов переводить на другие системы чтобы они не уходили насовсем к конкурентам, что настроить все не получается, что для того, чтобы получить автопарк на 15 бортов Iveco например нужно доказать состоятельность на каком-нибудь старом ЗИЛе или ГАЗе, где датчиков не понавешать, к аналоговым не прицепиться, а can шиной при производстве таких мамонтов и не пахло.

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

"Зачем в такой ситуации х/х учитывать? Это думаю, логично. Если надо учитывать - заполняем поле или включаем галочку, теперь же приходится многим предоставлять доступ к настройкам датчика, объяснять как делать и рассказывать логику работы алгоритма. Куда ж проще то?" - вовсе необязательно. Более того - как минимум два способа я вам озвучил в переписке.

"Простой пример. Ставим в настройках х/х 9 л. Машина 4с лишним часа простояла и проехала 150 км. В пробеге расход по расчету - 1,5*9=13,5л. А зачем в статистику ставится сумма и простоя машины за 4 с лишним часа? Сделайте тогда в статистике расход по расчету в поездках. Именно в статистике." - в статистике этот показатель есть итак.

"у нас 100% такие ситуации )))) это что нам щас надо бегать по объектам ставить всем датчики зажигания ??? PS: бегать ножками )))) по машинам я имею ввиду решение можно было сделать универсальным .. вкладкой/переключателем, пользователю позволить решать старый алгоритм или новый непонятный для них функцианал." - так решение и есть универсальное. Например - не нужен х/х - импортируйте всем зажигание на параметр speed - будет включено только, когда едет. Нужно точней - посмотрите в параметы, присылаемые объектом - возможно можно прицепиться к напряжению. Еще точней - да, как минимум can, а лучше - датчик зажигания.

Повторюсь - куда прописать "циферку" обязательно придумаем. Есть как минимум три разных варианта и один со звездочкой.

PS в приложении если кому-то интересно - датчик пробега (тип "счетчик" - можно переделать и на мгновенный пробег) с простой логикой - усредненная скорость на дельту времени. А также ДМРТ (спасибо SibNaviCom за кейс - по нему пришла идея) чтобы расход объекта привязать к "норме". Третий - сезонный коэффициент, чтобы "зимой побольше" на 22%.

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

и система не обязана менятся ))) у вас прямо идея фикс "делай чо хочешь но поменяй" ..
зачем кушать ложкой .. ложка уже всех достала , вы обязаны её поменять на чтото .. японцы вон палочками кушают )))))))

serd
Прошли почти сутки. одно сообщение в час. С одним объектом. Вы или пошлите меня на *** или простыми словами объясните за что и какой датчик отвечает. Создано 5 датчиков, значение которых не поддаются анализу. Соответственно в отчетах за вчерашний день каша. Я за второго клиента бьюсь, вот не поверите - я сам еще нифига не понял как заменить. Вы мне объяснить толком не можете, да, вы заменили датчики, помогли, но как я то клиенту объясню?! Создаю копию датчиков чтоб разобраться - они такую чушь несут... Сто тыщ коэффициентов... Это не развитие, это как палитра - сто тыщ раз мазнуть. чтоб цвет подобрать. только цвет у вас отличный был, премудрили.
По логам сможете восстановить - пожалуйста, восстановите у всех, где нет ДУТа, настройки.

serd  объясните пожалуйста, для чего пользователям надо видеть датчики обведенные красной рамкой в приведенном примере?

Что мешает использовать в таблице моточасы "потрачено по расчету в движении"? Пусть будет норма х/х введена корректная, чтобы математика коэффициентов работала, просто в отчете выводиться не будет.

Или именно в таблицу "сводка" добавить их? Тогда я +1.

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