-
Bonjour Visiteur, pour les QUESTIONS RELATIVES AUX PANNES : rendez-vous ici.
Merci par avance.
[Motorisation] Application Hybrid Assistant
- Auteur de la discussion justmv
- Date de début
Le roucaou
Membre HybridLife
J'ai un obdlink LX. Lorsque le contact est coupé, je ne peux pas m'y connecter en Bluetooth. Je pense que la prise ODB2 n'est donc pas alimentée sans le contact.
L'obdlink se met en veille lorsqu'il n'y a plus de trafic sur le bus CAN.
en règle générale, le réveil se fait lors du contact (saut de la tension à 13V).
l'alimentation 12V est permanente sur la prise OBD2.
la pin 16 est connectée au +12V (en général via un fusible).
et, en ce qui concerne le vlinker, voici une doc (très) technique
en règle générale, le réveil se fait lors du contact (saut de la tension à 13V).
l'alimentation 12V est permanente sur la prise OBD2.
la pin 16 est connectée au +12V (en général via un fusible).
et, en ce qui concerne le vlinker, voici une doc (très) technique
Merci mais c'est trop technique pour moi ...
Je lis quand même :
"
Support UART active, battery voltage drop, OBD bus active, key, etc. Up to 5 ways to wake
up from sleep mode."
En bref, est-ce déconseillé de laisser le vlinker branché sur le port obd pour risque de piratage ?
Je lis quand même :
"
Support UART active, battery voltage drop, OBD bus active, key, etc. Up to 5 ways to wake
up from sleep mode."
En bref, est-ce déconseillé de laisser le vlinker branché sur le port obd pour risque de piratage ?
JackyBrakmar
Membre HybridLife
A confirmer si t'oublies de verrouiller la voiture... par contre tu peux te retrouver, comma ça m'est déjà arrivé, en panne de batterie 12v. Un soir j'ai pas verrouillé la voiture, laissé le vLinker connecté et mon tél androïd dans la voiture. Résultat: batterie 12v vidée le lendemain.
Bonjour à tous
Pour ma prius gen 2 j'utilisais HA avec un Redmi note 12 sous Android 15 et un Carista sans aucun pb. Je viens de changer de tel et la patatra avec le Carista et un Pixel 8a sous Android 16 l'appli se deconnecte (perd la connection) après quelques secondes. A priori ce serait un bug Android connu de Google. Avez vous des retours, des suggestions à ce sujet ?
Pour ma prius gen 2 j'utilisais HA avec un Redmi note 12 sous Android 15 et un Carista sans aucun pb. Je viens de changer de tel et la patatra avec le Carista et un Pixel 8a sous Android 16 l'appli se deconnecte (perd la connection) après quelques secondes. A priori ce serait un bug Android connu de Google. Avez vous des retours, des suggestions à ce sujet ?
Bonjour, J'ai un gros doute à propos du "à priori" 
J'ai un pixel 8 sous sdk37 (android 17) et je viens de tester sur une toyota corolla avec un interface vlinker mc+.
HA marche tout à fait normalement.
la preuve en images:
pour aller plus loin, récupérer le fichier de debug et en coller le contenu ici.
aller dans Hybrid reporter/ envoyer les journaux de debogage , se les envoyer.
voilà le contenu de mon dernier test fichier debug attaché
Peut etre l'interface carista n'est pas à la hauteur pour le pixel? (j'ai toujours considéré que c'était un mauvais choix).
J'ai un pixel 8 sous sdk37 (android 17) et je viens de tester sur une toyota corolla avec un interface vlinker mc+.
HA marche tout à fait normalement.
la preuve en images:
pour aller plus loin, récupérer le fichier de debug et en coller le contenu ici.
aller dans Hybrid reporter/ envoyer les journaux de debogage , se les envoyer.
voilà le contenu de mon dernier test fichier debug attaché
Peut etre l'interface carista n'est pas à la hauteur pour le pixel? (j'ai toujours considéré que c'était un mauvais choix).
Merci pour ton retour et ton test. Je comprends le doute sur le Carista, mais j'ai analysé les logs de debug de mes dernières sessions (7 fichiers + le crash report) et le pattern est très reproductible, avec deux erreurs techniques précises qui me font penser qu'on n'est pas juste sur un mauvais adaptateur :
**Timing des déconnexions** (connexion établie → perte) :
- 6s / 38s / 33s / 27s / 9s selon les sessions
**Deux erreurs systématiques dans les logs** :
1. `IOException: bt socket closed, read return: -1` — le socket RFCOMM se ferme côté système pendant la lecture, pas côté app.
2. `NullPointerException` sur `BluetoothSocket.getInputStream()` — l'app tente de lire un flux sur un socket qui, malgré le message "Serial connected successfully", n'a en réalité jamais été correctement établi côté OS.
Ça semble correspondre très précisément au bug documenté sur la pile Bluetooth d'Android 16 : un conflit entre le nouveau stack LE Audio et les anciens profils Bluetooth classiques (SPP, HFP, A2DP), qui provoque une fermeture prématurée du socket lors de renégociations de codec. Un article qui détaille bien le mécanisme : https://www.hawkdive.com/android-16-bluetooth-disconnect-fix/
Le bug touche aussi Samsung (S24/S25), Nothing Phone 3 et Motorola Edge sous Android 16 stock — donc pas spécifique aux Pixel ni au Carista en particulier.
Ton test avec le vLinker MC+ sur Pixel 8 (Android 17) qui fonctionne bien pourrait justement s'expliquer si le patch inclus dans Android 17 corrige (au moins partiellement) ce problème de socket.
Je peux joindre les fichiers de logs complets si ça t'intéresse pour creuser plus précisément où le socket meurt côté firmware Android. Merci en tout cas pour ton aide
**Timing des déconnexions** (connexion établie → perte) :
- 6s / 38s / 33s / 27s / 9s selon les sessions
**Deux erreurs systématiques dans les logs** :
1. `IOException: bt socket closed, read return: -1` — le socket RFCOMM se ferme côté système pendant la lecture, pas côté app.
2. `NullPointerException` sur `BluetoothSocket.getInputStream()` — l'app tente de lire un flux sur un socket qui, malgré le message "Serial connected successfully", n'a en réalité jamais été correctement établi côté OS.
Ça semble correspondre très précisément au bug documenté sur la pile Bluetooth d'Android 16 : un conflit entre le nouveau stack LE Audio et les anciens profils Bluetooth classiques (SPP, HFP, A2DP), qui provoque une fermeture prématurée du socket lors de renégociations de codec. Un article qui détaille bien le mécanisme : https://www.hawkdive.com/android-16-bluetooth-disconnect-fix/
Le bug touche aussi Samsung (S24/S25), Nothing Phone 3 et Motorola Edge sous Android 16 stock — donc pas spécifique aux Pixel ni au Carista en particulier.
Ton test avec le vLinker MC+ sur Pixel 8 (Android 17) qui fonctionne bien pourrait justement s'expliquer si le patch inclus dans Android 17 corrige (au moins partiellement) ce problème de socket.
Je peux joindre les fichiers de logs complets si ça t'intéresse pour creuser plus précisément où le socket meurt côté firmware Android. Merci en tout cas pour ton aide
Probablement un pb d'autorisation car tu serais considéré comme un participant peu actif sur ce forum.
Mais compte tenu de ta maitrise du sujet, je pense inutile de joindre ton fichier de debug.
je n'ai jamais rencontré d'utilisateurs de HA aussi calé en environnement android
et de toute façon, les développements de HA sont officiellement arrêtés.
Mais compte tenu de ta maitrise du sujet, je pense inutile de joindre ton fichier de debug.
je n'ai jamais rencontré d'utilisateurs de HA aussi calé en environnement android
et de toute façon, les développements de HA sont officiellement arrêtés.
Oula je te rassure je ne suis pas calé en Android j'ai juste utilisé Claude pour m'aider à analyser la situation. Mais méfions-nous des IA qui peuvent aider surtout quand on maîtrise le sujet mais qui peuvent aussi nous balader. Ça te semble cohérent ce qu'elle raconte ?
Je viens de t'en donner les droits.
Et pour info, même problème pour moi il y a 3 jours, dans ma Prius 4, avec HA connecté via OBDLink LX à mon Pixel 8a, Android 17, juste avant d'installer sa dernière MAJ (celle du 1er juillet 2026).
Pour les 3 tentatives effectuées alors, je trouve dans les 2 premiers fichiers :
SCANNER: Connection lost at speed 24
SCANNER: Connection lost at speed 51
Et dans le 3ème :
SCANNER: AStream_Error: (IOException) java.io.IOException: bt socket closed, read return: -1
A chaque fois, j'ai (re)branché le connecteur OBD, je suis allé dans l'écran qui reprend les vitesses des 3 moteurs, je suis parti de l'arrêt, et l'écran de HA s'est bloqué au bout de quelques secondes.
Ceci dit, le Bluetooth était également connecté au véhicule pour le main libre, et à Android Auto (mais via câble USB, et c'est un des modules qu'on trouve sur AliExpress, tel que détaillé ici).
Je n'avais plus employé HA depuis longtemps, vu que j'ai un ScanGauge connecté en permanence...
Je voulais simplement visualiser les variations de régime en temps réel entre ICE, MG1 et MG2.
Je vais essayer à nouveau aujourd'hui, donc après MAJ de Android.
Pour les 3 tentatives effectuées alors, je trouve dans les 2 premiers fichiers :
SCANNER: Connection lost at speed 24
SCANNER: Connection lost at speed 51
Et dans le 3ème :
SCANNER: AStream_Error: (IOException) java.io.IOException: bt socket closed, read return: -1
A chaque fois, j'ai (re)branché le connecteur OBD, je suis allé dans l'écran qui reprend les vitesses des 3 moteurs, je suis parti de l'arrêt, et l'écran de HA s'est bloqué au bout de quelques secondes.
Ceci dit, le Bluetooth était également connecté au véhicule pour le main libre, et à Android Auto (mais via câble USB, et c'est un des modules qu'on trouve sur AliExpress, tel que détaillé ici).
Je n'avais plus employé HA depuis longtemps, vu que j'ai un ScanGauge connecté en permanence...
Je voulais simplement visualiser les variations de régime en temps réel entre ICE, MG1 et MG2.
Je vais essayer à nouveau aujourd'hui, donc après MAJ de Android.
dans les logs ci-dessus, je n'ai pas vu de déconnexion.
par contre, il y a des "SCANNER: short answer ignored" cela correspond à des réponses "multiframe" (en provenance d'un ECU) incomplètes.
il manque au moins une trame. cela provient de l'interface qui ne suit pas la cadence ou du canal de transmission SPP qui sature.
Normalement, HA se contente d'ignorer ces anomalies temporaires.
par contre, il y a des "SCANNER: short answer ignored" cela correspond à des réponses "multiframe" (en provenance d'un ECU) incomplètes.
il manque au moins une trame. cela provient de l'interface qui ne suit pas la cadence ou du canal de transmission SPP qui sature.
Normalement, HA se contente d'ignorer ces anomalies temporaires.