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

serd Что-бы народ больеш понимал лучше не пиши x,a,b
Лучше X и Y. Так понятней.

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

Вот смотрю в карточку объекта и вижу там формулу
(speed-#speed)/const2

И так по всем объектам. Так всё-таки сумма или разность пополам?

KO - я бы сказал, что все зависит от. Ваша позиция понятна, но при ней многие пересчеты остаются "за кадром" - что считает, как, в каких отчетах.

Формулы хостинга (а именно пересчет датчиков) - это простая математика, которая преподается с пятого класса школы. Скорость и расстояние - с седьмого. Например Y=aX+b и V=s/t - на этом и построен расчет на данный момент. Более того - таким он был и до этого только многого вы не видели.

Как альтернативу там, где просят простоты предложите создать датчик зажигания и прописать норму там - литры в час, что может быть проще. Если нужно расстояние - предложите применять датчик пробега (если он конечно есть у объекта). Опять же - можете написать мне и я с радостью настрою датчик за вас (если он конечно один).

Beifuss без проблем - вот та же норма на скриншоте (параметр у датчика time:d тип - ДПНД) парами XY.

у объекта было лето 10, зима 12,с первого декабря до 30 февраля (естественно, такого дня нет - он нужен только для определения конца месяца и в интерфейсе был 1 марта)
х/х по классике 2

table row x: 0; a: 0; b: 3.48;
table row x: 60; a: 0; b: 2.9;
table row x: 334; a: 0; b: 3.48;

60 - это номер дня, полагающийся на начало марта, 334 - начало декабря.

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

Скрипт запущен и изменения вступили в силу.

Мы ожидаем, что к завтрашнему утру ситуация разрешится "по горячим следам".

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

"Надо убрать видимость датчиков "eng_eff_on_fuelconsmath" и "eng_eff_on_fuelconsrates" " - флаги видимости для этих датчиков создавались на основе видимости данных из секций расчета. Здесь предлагаю сделать проще - пришлите мне на serd@gurtam.com, пожалуйста, имя вашего сервиса и мы запустим видимость для него.

да - если вы уже меняли созданные датчики самостоятельно - к ним изменения не применялись, однако если это все-же необходимо - пришлите, пожалуйста, наименование вашего сервиса мне на serd@gurtam.com

....все через боль....

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

table row x: 0; a: 0; b: 3.48;
table row x: 60; a: 0; b: 2.9;
table row x: 334; a: 0; b: 3.48;

Откуда эти цифры 3.48 2.9? и Как вы их получили?

У нас клиенты постоянно "играются" с расходом. И как им вот Это объяснить. Программа должна упрощать а не усложнять жизнь людей.

Суть в том, что клиент  большинстве своём скажем так "воспитан" к тем или иным условиям. Если изначально у клиента есть доступ к изменениям в УЗ то с расчётом норм проблем не должно возникнуть, НО ведь есть клиенты у которых доступ ограничен и функционал УЗ соответственно тоже, настройки в этом случае придется делать нам своими руками, опять же всё это займет достаточно много времени. Я согласен с мнением что сервис должен быть максимально удобен, но с другой стороны и ваша позиция ясна и правильна. Но всё же резкие изменения как правило обрушивают на вас шквал негативных отзывов, и на нас соответственно. По хорошему конечно вебинар пораньше бы провести, просто все здесь находящиеся понимают какой оборот сейчас все нововведения примут, тем более что сами еще не совсем разобрались что как работает.

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

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

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

Еще вопросы по общему датчику с добавкой "_automation", вы случайно не удалили эти датчики, сейчас попалась несколько объектов без них, с двумя баками.

К вопросу видимости датчиков "eng_eff_on_fuelconsmath" и "eng_eff_on_fuelconsrates", я правильно понимаю что для отключения видимости этих датчиков надо обратиться к вам и сообщить учетку под которой надо выключить видимость? Вы хотите сказать, что видимость этих датчиков с такими названиями кому то нужна?

KO 

"Еще вопросы по общему датчику с добавкой "_automation", вы случайно не удалили эти датчики, сейчас попалась несколько объектов без них, с двумя баками." - убрали automation из названия, чтобы названия попали в маски в шаблонах и уведомлениях, у кого были.

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

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

sccop

"Почему не проверили на тестовой ветке как следует?" - проверяли и не раз, скрипты приведения к новому алгоритму проверялись в режиме эмуляции до запуска, подготовка к этому обновлению длилась месяц и была привлечена группа сотрудников - для анализа use-cases, работы и прочего. И тем не менее - все варианты мы предусмотреть не смогли, именно поэтому всем причастным уже донесены меры их ответственности (в том числе и мне).  И именно поэтому мы приносим извинения, что не спросили у всех и каждого, согласны ли вы с этим или нет.