Унификация наименований Датчиков в Шаблонах отчетов Wialon

Не понимаю как это будет выглядеть.

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

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

Поясните более подробно свою идею.

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

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

И вы сейчас предлагаете обязать всех использовать только определенный имена и определенное количество этих переменных?

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

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

Речь не о мелком сервисе "удобств", а принципиальном подходе: унифицировать основные датчики, сделать жесткое название для основных датчиков. Десятка 2-4. Отсюда - переносимость отчетов. Отсюда - однообразное понимание интегратора, производителя "железа" и техподдержки Гуртам.
Пожертвовать частью гибкости ради ясности.

Запишите в протокол:
Я против жертвовать гибкостью системы ради понимания моей настройки кем-то.
Если нужно передать настройку я объясню что да как.
Я и мои сотрудники могут прочитать настройку даже очень запутанно настроенного объекта и у нас есть свои стандарты настройки внутри компании.

По мне так лучше не название датчиков унифицировать, а имена переменных. Вот это было бы удобно.

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

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

Я не поддержу в таком виде.
Как по мне, лучше реализовать шаблоны объектов в соответствии с типом терминала.
Например на том же галилео 5.x/Сигнал/Смарт мы в 98% случаев заведем:
- Питание (pwr_ext)
- АКБ (pwr_int)
- Зажигание на IN1 или adc1 (кому как больше нравится)
- ДУТ на 485й 1 адрес (+ температура, при наличии)
- Температура терминала.

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

Хотелось бы две опции:
- мои типовые настройки для счетчиков, топлива, детектора поездок и т.п.
- типовые датчики для определенного типа терминала.

Есть. Но сотрудников больше чем 1, также как и компьютеров с которых можно работать.
Ну и искать каждый раз файл приходится.
Уже сейчас быстрее и проще копировать существующий объект.

Ну и набор типовых датчиков по виду оборудования решит проблему топик-стартера.

А это вроде от протокола железки зависит, если прибор шлет это в adcxx, то и в Wialon'е оно adcxx

Ну а я про что?
А можно сделать кнопочку рядом с типом оборудования - применить типовые настройки. И получить настроенный объект

Дело в смысле, а в протоколе. Так Gurtam'у придется дополнительный транслятор делать из родного протокола, где "param" приходит в человеческий "fuel_level"

Думаю потенциала не увидят.