Comments 44
Классный проект)
Ценность таких приложений в том что они знают конкретные машины. И умеют менять в них что-то.
А это большая база которую бесплатно не собрать. И экспериментировать дорого. Машины отлично кирпичатся.
Справедливо. Собрать базу по всем протоколам в одиночку нереально. Именно поэтому я смотрю в сторону опенсорс-решений, а в будущем и добавлении плагин системы для приложения,чтобы люди могли сами собрать "свои фичи" под нужную марку машины.
Что касается экспериментов - для этого и пишутся эмуляторы, чтобы сначала откатать логику на софте, а уже потом подключаться к реальному железу.
Понятно, что собрать все тонкости каждой марки задача на миллион лет, но с правильным инструментом тестирования и помощью комьюнити это становится решаемой инженерной задачей.
могли сами собрать "свои фичи" под нужную марку машины.
И вот тут непробиваемая стена будет. Разбираться что там говорит современная машина это прямо очень сложно. И довольно мало кто умеет. Те кто умеют обычно при деле и умеют монетизировать свои знания.
Что касается экспериментов - для этого и пишутся эмуляторы, чтобы сначала откатать логику на софте, а уже потом подключаться к реальному железу.
А это так просто не работает. Вы не можете узнать как машина отреагирует на то или иное изменение. И какое изменение надо внести чтобы получить желаемый эффект.
Я бы на вашем месте поискал документацию или даже открытую базу на что-нибудь относительно старенькое. Купил бы такую машину и сделал бы ее поддержку. С тестами на реальной машине. Это выглядит реальным.
Согласен, реверс-инжиниринг современных протоколов явно дело не легкое. Но я и не пытаюсь конкурировать с дилерским софтом для прошивки.
Мой фокус сейчас - стандартизированный мониторинг. OBD предоставляет огромный пласт данных, которые одинаковы для большинства машин, и эмулятора вполне достаточно, чтобы отладить их парсинг и визуализацию.
Что касается плагинов - это задел на будущее. Да, спецов мало, но именно отсутствие открытой и удобной платформы мешает им делиться наработками. Я хочу создать "песочницу",а наполнение придет со временем».
Все интересное как правило нестандартное. Нужное тоже. Еще одна утилита которая ничего не может так себе план.
И даже стандартное надо отлаживать на реальной машине. Практика показывает что любые подобные эмуляторы ошибаются время от времени.
Справедливый скепсис. Ошибка любого эмулятора в том, что он слишком идеален по сравнению с машиной.
План "сделать еще одну читалку" действительно так себе. Мой интерес здесь скорее в создании расширяемой системы. Если получится сделать так, чтобы добавление "нестандартного" функционала под конкретную марку занимало минимум времени через плагин, то стена станет чуть менее непробиваемой. Но я согласен - без тестов на живых блоках и поиска документации по старым протоколам далеко не уедешь. Буду искать "подопытных"😁
Если говорить про базовый уровень, т.е. ЭБУ двигателя, то это наверное 90% задач по диагностике и ремонту, и хорошая новость в том что эти протоколы CAN для большинства машин стандартные. Потому что исторически это Bosch. Для ремонта двигателя не нужно ни чего менять, нужно произвести диагностику, считать показатели с датчиков - ДАД, ДМРВ, лямбда, обороты задающего диска и т.д. свериться с паспортными данными, тоже по ходовке, вернее ABS/ESP, также производитель Bosch, на большинстве машин протоколы CAN стандартные. Эта система также даёт инфу о скорости движения, положении руля.
Это далеко нет так) это как говорить что tcp стандартный, поэтому что уж там в интернете, все одинаково
Аналогия с TCP на самом деле отличная, но она скорее подтверждает жизнеспособность подхода, чем опровергает его. Мы ведь не отказываемся от идеи создания браузеров только потому, что контент на всех сайтах в интернете разный. Да, CAN и транспортные протоколы -это всего лишь база, но поверх них давно существует стандарт UDS, который определяет саму механику общения с блоком. Тот факт, что конкретные идентификаторы данных у разных производителей могут отличаться - это не непробиваемая стена, а просто вопрос наполнения базы. Именно для этого я и проектирую систему плагинов, чтобы архитектура приложения была универсальным «движком», а специфика конкретных блоков подтягивалась отдельно.
Игнорировать общность тех же Bosch-платформ тоже глупо, на деле везде под капотом плюс-минус понятные стандарты, которые и позволяют создавать универсальные инструменты.
Хорошо, я наверное недостаточно точно выразился, но не хотел углубляться. Бортовая шина CAN автомобиля к которой подключается EML и слушает, тут понятно. То что пропускной способности CAN недостаточно для некоторых автопроизводителей и они добавляют ещё шины, т.е. в автомобиле может быть проложено несколько отдельных шин и модуль обмена между ними если это требуется. В этих шинах могут быть блоки управления климата, матричных фар, поворотников, освещения салона и т.д. в современных автомобилях по CAN может управляться всё что угодно и там везде будут свои коды. НО! Шина CAN на ЭБУ, ABS/ESP имеет стандартные пакеты, потому что это Bosch, и даже если не он, то всё равно тот блок будет выдавать стандартные пакеты, потому что зачем новый велосипед, про который ни кто не знает в сервисе.
Флаттер и дарт... А зачем?
Можно было завести нормальную платформу, нормальным инструментом, нормальным перфом и зрелым умным комьюнити. А сейчас это сброд из фронтендеров которые ничего не знают о производительности мобилок.
Kotlin почему не стали использовать?
А компания Apple давно уже разорилась?
Kotlin/Compose - крутая технология, но его попытки оставаться "нативным" часто выходят боком на специфическом железе. Когда работаешь с китайскими ГУ,где Android переписан левой пяткой, системная верстка может поплыть в любой момент. Flutter же рисует все сам.
Кроме того, проект не замыкается на одном Android. Мне нужна была платформа, на которой я смогу с минимальными правками запустить один и тот же код на iOS, Windows и планшетах. В плане зрелости десктопа и стабильности сложной графики на разных системах Flutter сейчас банально практичнее.
Можно поискать в открытых проектах их базы и парсеры к ним и использовать их. Хотя давно не видел, да из-за засилия платных и не смотрел.
Знаю, база имеется. Есть проекты для вдохновения так сказать. Но у них тоже в большем ограниченный функционал.
Так надо, по моему мнению, сделать какую либо описательную модель индикатора (тип - циферблат, табло или просто “лампа” или “символ”, условия запроса, проверки правильности и пересчета и условий отображения). Потом уже будет адаптация баз к индикаторам, отдельно, как я понял отработка нештатной работы всего этого зоопарка, именуемого elm :)
Именно к такой архитектуре я и иду. Идея с декларативным описанием индикаторов по моему мнению единственный вариант оставить чистую и понятную архитектуру.
А "зоопарк ELM" это отдельная тема)), которую я планирую инкапсулировать в нижнем слое приложения. Чтобы верхний уровень UI работал с чистыми данными и не знал о том, сколько раз адаптер блефует при запросе нестандартного PID-а. В этом и будет суть плагинов (которая уже есть в дорожной карте проекта) - описал модель данных и привязал её к визуальному компоненту.
Планируется ли релизиться на F-Droid? Кстати, там есть ELM327 Emulator, вдруг будет полезно?
Прикольно. Буквально месяц назад я сам столкнулся ровно с теми же мыслями - а почему бы не сделать. Open source приложение для OBD2. Для андроида (я сам андроид девелопер)
Даже начал изучать протокол и всё такое, но понял:
1) тема достаточно нищевая
2) очень много вариаций - каждый производитель имеет свои уникальные матрицы, которые отличаются от других, и часто доступ к ним закрыт
3) уже очень много есть таких приложений, которых для обывателя вполне достаточно - скинуть ошибку, прочитать параметры (для более продвинутых есть хакнутые версии, к чему я не призываю)
4) Для сервисов есть фирменные решения, которые гарантируют работу с брендом/концерном.
Также для сервиса лучше 1 раз купить тот же launch, чем иметь возможность окирпичить какой-либо блок или вообще машину неправильной командой от опен-сорса, который ни за что не отвечает и ничего не гарантирует. Что, на мой взгляд, очень сильно подрывает желание таким пользоваться.
На самом деле OSS приложения для OBD вполне себе существуют, например AndrOBD.
Но на F-Droid оно такое пока одно, надеюсь, что скоро их станет как минимум 2 ))
Благодарю за честный разбор. Моя цель не соревноваться с дилерским софтом по типу launch, это было бы самоубийством. Моя цель здесь скорее инженерная - создать гибкий и современный "движок" для визуализации данных, которого сейчас на рынке очень не хватает.
Проблема большинства существующих приложений в их закрытости и дизайне из эпохи 90-х, а я хочу дать людям открытую платформу с системой плагинов, где знающий человек сможет сам описать нужную матрицу своей машины через конфиг, не переписывая все приложение. Что касается рисков, то в режиме Read-only стандартных PID окирпичить что-либо физически невозможно, это безопасная зона мониторинга, с которой я и начинаю.
Я реалист и понимаю, что в одиночку все тонкости не собрать, поэтому мой план это сделать архитектурное ядро, чтение ошибок и систему расширений. Если энтузиасты подтянутся, то вместе мы сможем сделать действительно качественный открытый продукт.
Те приложения для EML что я смотрел, полный отстой в плане UX, интерфейс максимально недружественный, параметры свалены в одну кучу, нет нормальной группировки, нет поиска, потому что нет понимания реальных задач, для чего нужен этот инструмент.
Flutter и Dart это конечно весело, но вся ценность с CAN протоколе конкретных производителей, ваша красивая картинка не нужна, нужна функциональность, профессионалы работают с данными, а не с няшным интерфейсом, вы путаете и мешаете характер продуктов.
Ну и самое главное и важное, CAN протоколы хотя и стандартизированы, UDS, к примеру, но реализация везде своя проприетарная, это ключевая проблема для open source, все данные которые сейчас доступны обществу, по сути это утечка конфиденциальных данных производителя, через различные способы.
Ценность показометра скорости ну прямо скажем никакая, а как только копнете глубже, столкнетесь именно с закрытостью данных, кто их уже собрал ценит свой труд и свое время, и хочет получить за свой труд вознаграждение, что вполне логично.
А современные автомобили приходят уже к шифрованию CAN сообщений, помимо подписей и шифрования флеша и наступает эра когда ваш автомобиль уже не принадлежит вам.
Ваш тезис про то, что автомобиль перестает принадлежать владельцу из-за шифрования - лучший аргумент в пользу Open Source. Чем сильнее закрываются производители, тем важнее иметь открытые инструменты, которые позволяют хотя бы базово понимать, что происходит с твоим "железом“.
Да, «показометр скорости» - это база, но с чего-то нужно начинать. Если архитектура позволит сообществу легко добавлять свои находки по конкретным блокам, то проект быстро выйдет за рамки базовых параметров.
Надо двигаться в направлении управляемого извне распространения закрытых данных автопроизводителя.
А ещё вам с догонку, читать параметры автомобиля через диагностику, это самый плохой способ реализации, установка этого в автомобиль в режиме постоянной работы, означает что внешняя диагностика не сможет работать с ECU авто, тем более при наличии вам нужной инфы в системной шине данных, но, ой, опять приходит, что данные проприетарные.
Китайские автомобили, отдельный пласт г.на, где нет ни документации, ни описания, ничего, дак ещё и поколения меняются как смартфоны.
Китайские клоны elm, прям удачи вам в удаленной диагностике, когда пользователи начнут ставить приложение.
поллинг через OBD2 действительно не идеален для режима Always-on, и про занятую диагностическую сессию я в курсе. Но давайте честно, для Open Source проекта это единственный входной билет.
Слушать шину пассивно идея крутая, но она моментально разбивается о те самые проприетарные данные, про которые вы сами написали. Чтобы сделать универсальный пасивный монитор, нужно иметь бюджет в автопарк)
Про китайские ELM и зоопарк машин тут согласен на 100%, это будет ад для техподдержки. Но я и не планирую лечить все болезни мира сразу. Начну со стабильной базы для большинства, а проблемы кривых клонов будем решать фильтрацией на уровне софта или рекомендациями по "железу".
Привет. Если вдруг надо помочь с документацией, буду рад любым способом. Много копался в своё время с PIN на BMW, рад, если буду как-то полезен
Это же не ваше приложение?
Скрытый текст
В идеале иметь приложение-дашборд по типу графаны, где каждый виджет/график можно настраивать используя произвольные pid'ы (или как там называется это вот, чтобы уникальную метрику получить, которая только на этой модели бывает).
Тогда сообщество само добавляет pid'ы и дашборды в общую библиотеку, как это сделано в той же графане.
В этом приложении так можно?
Не спорю, концепция "графаны" это идеальный вариант. Сейчас, на этапе MVP, я действительно планирую захардкодить основные дашборды, чтобы отточить стабильность и дизайн. Но архитектуру (те самые плагины) закладываю с прицелом на то, чтобы позже прийти именно к такой гибкости, когда пользователь сам сможет "собирать" экран под свои нужды и PID"ы
Неужели никто не заметил, что автор отвечает, как нейросеть?
Почему нормальное OBD2-приложение должно быть open-source