Aller au contenu

Lucas.D

Membre
  • Compteur de contenus

    118
  • Inscription

  • Dernière visite

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

  1. J'avais aussi les radars mais seulement en audio, pas la partie visuelle. D'accord donc pas le même problème.
  2. Tu as vérifié que c'était pas tout le système de l'écran tactile qui était freese ? J'ai aussi eu ma caméra de recul qui ne s'affichait plus, mais tout l'écran était bloqué (même après appui sur les boutons tactile en dessous), pourtant j'avais toujours la radio. Ca ne m'est arrivé qu'une seule fois et c'est après la dernière mise à jour du système, sur le moment j'ai coupé et rallumé la voiture sans amélioration visible j'ai dû redémarrer complètement l'écran (appui long sur le symbole téléphone).
  3. Je ne sais pas si c'est lié à la mise à jour, mais hier j'ai rencontré un crash de l'écran tactile. Les boutons tactiles sous l'écran (10") ne faisait rien et impossible d'avoir l'affichage de la caméra de recule (écran figé sur le menu des radios). Sinon le i-cockpit et la voiture marchaient correctement, j'avais aussi les bips de proximité qui fonctionnaient. Première fois que ça m'arrive en 9 mois. Si jamais ça vous arrive vous pouvez rester appuyer sur le bouton tactile du téléphone pendant une dizaine de seconde pour forcer un redémarrage (ça ne gène pas la conduite).
  4. Le siège chauffant qui ne consomme rien ?
  5. D'après la documentation des APIs (les interfaces de communication que l'application utilise), la voiture rafraîchit les données plus ou moins une fois par minutes, et elle peut aussi contacter avant ce délai en cas d'un événement (ex: allumer la voiture). Donc si on demande un rafraichissement des données ça peut aller de trés rapide à très lent suivant où on en est dans la fenêtre de rafraîchissement. Certaines parties de la doc laisse à penser que les modèles récent peuvent même envoyer des données plus fréquemment, mais je ne serais pas étonné que ça s'applique uniquement quand la voiture est réveillée. Et que le taux de rafraîchissement ralentisse après le passage en mode veille/basse consommation du système de l'écran. En tout cas c'est ce que j'ai compris de la doc. Notamment de l'image présente à la toute fin de cette page.
  6. Effectivement suite à la mis à jour du 19 novembre, @flobz a mis en place un système pour récupérer localement les client_id et client_secret (bien joué !). En informatique ce n'est pas parce que tu as accès à une information que tu en fait ce que tu veux sans conséquence. Personnellement je n'ai pas la prétention de dire que je sais ce que PSA va faire si ces données sont utilisés, et publiées. Mais par mesure de précaution je ne joue pas avec le feu et j'ai averti que ce ne sont pas des client_id et client_secret qui nous appartiennent. Qu'un particulier utilise ces informations qu'il a récupéré par lui même pour déployer une application localement, qu'il est le seul à utiliser c'est une chose (et peu d'entreprises vont se plaindre de ce genre de comportement). Par contre donner accés direct aux données d'identifications et ou les utiliser pour une application alternative, pour moi tu changes de contexte et donc les réactions possibles. A vous de voir ce que vous faites avec. Mais je reste en désaccord avec les propositions de le partager publiquement, c'est mon avis, je le partage point final.
  7. Je ne comprends pas ce que tu sous entends par là
  8. Je ne comprends ce qui parait compliqué dans "appartiennent à PSA" et " identifier l'app MyPeugeot". Les client_id et client_secret appartiennent à PSA, au même titre que les "login/pass qui sont eux personnels" nous appartiennent. Encore un autre détail, ces client_id et client_secret sont récupérés dans un fichier après un premier échange avec l'API, et ils ne sont pas à ma connaissance présent dans l'application à tout instant. Par défaut, ce fichier n'est PAS accessible par mesure de sécurité et on est obligé de déployer une version modifiée de l'app pour contourner cette sécurité. Je ne sais pas si ces client_id et client_secret sont visible depuis le réseaux, je ne me suis pas amusé à spy et même si c'était le cas ça ne reste pas une bonne idée de les utiliser parce qu'ils sont visibles... Mais toujours est il que dire aux personnes comment récupérer les client_id et client_secret et les donner c'est pas la même chose.
  9. Je rappel que ce sont des identifiants pour l'API et que ces identifiants appartiennent à PSA pour identifier l'app MyPeugeot. Donc oui tu peux les donner mais je me pose toujours la question de la légalité de partager ce genre de données qui ne sont pas censées être accessibles sans modifications de l'app.
  10. Le problème c'est que le client_id et le client_secret sont propres à l'application. Quand tu utilises une API PSA, tu commences par créer un compte sur leur plateforme développeur, puis tu déclares une application. Cette déclaration te permet juste de donner un nom et une description (ainsi que de préciser des redirects URI valident mais ça c'est un autre sujet) et en retour tu reçois de la part de la plateforme développeur les [ client_id & client_secret ]. Ces identifiants te permettent de communiquer à l'API que c'est bien l'application portant le nom indiqué et appartenant au compte développeur X qui est en train de faire cette requête. L'autre problème qui se pose c'est que sur les APIs présentent sur le site aujourd'hui il faut que les application souscrivent à des formules pour pouvoir utiliser les APIs. Ces formules définissent un maximum de requêtes par heure, par jour ou autre, et il peut exister des versions payantes de souscription qui vont au delà des 100 requêtes par jours que certaines API proposent (un exemple de nombre aléatoire). Donc pour le moment certains d'entre nous somme allez chercher des informations d'identifications appartenant à PSA permettant d'identifier l'application MyPeugeot, et qui a surement un accès illimité en nombre de requêtes aux différentes APIs. Donc on ByPass tous leurs layers de sécu et on utilise notre application en tant que MyPeugeot sur une API qui n'est même pas officiellement disponible. Donc moi je ne veux pas prendre de risque, je viens de m'en rendre compte et j'arrête toute utilisation de ces identifiants qui ne m'appartiennent pas et qui ne sont pas liés à mon compte spécifiquement. Donc le résumé : [ client_id & client_secret ] sont des informations qui permettent d'identifier l'application MyPeugeot sur les APIs de PSA. Les utiliser nous fait passer pour l'application MyPeugeot et on passe complètement à côté des restrictions qu'on est censé avoir. Tu as le droit d'utiliser l'API mais avec tes propres identifiants et aujourd'hui tu n'en as pas car ce n'est pas encore disponible. Et le problème vient bien du fait que tu n'es PAS propriétaire des identifiants que tu utilises. Ceci est ma compréhension du sujet qui peut être erronée. C'est juste des hypothèses, mais je sais que par exemple il existe des carte SIM spécials objets connectés qui offrent la possibilité de se connecter à l'international, chaque pays ayant un ou plusieurs opérateur compatible. Le problème c'est que les coûts de ces cartes sont souvent démentiel pour la capacité qu'elles proposent parce qu'elles se bases sur les tarifs des pays les plus chers. Mais ce ne sont toujours que des hypothèses.
  11. @LelasC'est vrai que c'est une bonne idée de faire un retour. J'ai utilisé les mêmes outils suite à l'installation de Android Studio. Mis à part le temps de téléchargement avec ma co aucun soucis la dessus. Pour ma part le patch fonctionne sur la version 1.26.1 que l'on peut récupérer grâce à cet outil de téléchargement d'APK. Pour le refus d'installation tu as surement dû rencontrer l'erreur suivante si tu lances l'installation de l'APK depuis un terminal avec adb : INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2 Si c'est le cas c'est parce qu'il faut changer deux choses dans le `AndroidManifest.xml` : "android:allowBackup" qui doit être passer à vrai (comme dit dans le tutoriel). "android:extractNativeLibs" qui doit aussi être passer à vrai pour faire disparaître l'erreur précédente Si on lance directement des requêtes après connection et synchronisation (en rentrant le code envoyé par SMS) sans rien executer les codes ne semblent pas être récupérés. Par contre après avoir lancé un préconditionnement les informations semblent être présentes (client_id, client_secret, etc). L'utilisation du WSL simplifie beaucoup le travail si on est habitué au terminal Linux, et évite les problèmes liés à Windows. Un problème persiste cependant, le script python tente de chercher le client_id et le client_secret à la racine du JSON qu'il génère temporairement, alors qu'ils semblent être présent en dessous du VIN dans l'arborescence (un changement entre la 1.25 et la 1.26 ?). Les deux valeurs que j'ai pu observer sont identiques. Donc les client_id que l'on utilise ne sont pas fait pour notre usage et nous utilisons les identifiants propres à l'application MyPeugeot. Je vais donc arrêter de les utiliser car il ne sont pas propre à mon compte (le doute régnait encore avant pour moi). Et je vais attendre le déploiement de l'API V4 pour les End Users, afin de pouvoir me doter de mes propres clés et éviter de contourner trop les règles de sécurité en vigueurs (est ce que ça peut amener des problèmes légaux aussi ?). Libre à vous de faire ce que vous voulez.
  12. La solution la plus simple aujourd'hui c'est une wallbox, la pulsar de la marque WALLBOX me permet de mettre une heure de début et de fin. Il existe surement des prises connectées (à l'instar de la NRGkick, dans le sens ou elle est connectée, mais je ne sais pas si elle peut démarrer et arrêter à des heures données) qui permettent aussi de le faire mais il faut chercher
  13. Le calcul de l'horaire ne marche pas forcément, l'intensité peut varier au cours de la nuit, toujours dans mon exemple de WallBox, j'ai un régulateur (ce n'est pas le bon mot) qui empêche la consommation globale de la maison de dépasser celle souscrite à EDF (c'est particulièrement important quand on a le Linky qui ne pardonne pas). L'appareil qui est limité c'est la wallbox elle même, si en plein milieu de la nuit le ballon d'eau chaude et les radiateurs se mettent en marche la vitesse de recharge baisse. Et même si ce n'est pas à base d'internet, la consommation en données mobile va largement augmenté par rapport à celles qui passent aujourd'hui, après à voir le type de contrat que Peugeot à signé pour cette connectivité. Et la perte de réseau est encore un bon point contre cette solution à terme !
  14. Personnellement je recharge sur une wallbox 7.4kW, donc 15 min de recharge représente un peu moins de 5% de gain. Mais toujours d'un point de vue du constructeur, il vaut mieux ne pas implémenter une fonctionnalité que de mal l'implémenter. Dire aux utilisateurs, "vous pouvez arrêter la charge à 80%" mais que par moment ce soit 81, 85, ou 82 suivant la chance, ça ressemble plus à une fonctionnalité qui ne marche pas correctement qu'à un résultat attendu. Pour moi la seule vrai façon de faire c'est de garder le principe de peu de communication avec le véhicule, il sait répondre et envoyer des données mais il ne doit pas le faire continuellement. Il faudrait donc modifier le soft de la voiture pour qu'elle se coupe d'elle même et puisse remonter l'information de l'arrêt. Autre problème avec la technique décrite, l'arret n'est pas terminal, il l'est jusqu'à ce que l'on débranche ou que l'heure de charge différée soit atteinte.
  15. La manière dont la solution est implémenté ici est un peu spéciale et ne serait pas une solution envisagée pour contrôler l'ensemble de la flotte de véhicule peugeot. L'idée derrière l'implémentation de @flobz est de demander toutes les minutes l'état de charge du véhicule, si il a atteint la valeur, on arrête la charge, sinon on fait rien, et dans tous les cas on rappel le même procédé dans 60s. Le faire unitairement sur certains véhicules ne pose pas de problèmes, par contre faire 10 000 requêtes juste pour ça toutes les minutes, ça commence à coûter cher, et encore pire à l'avenir si la voiture continue de rester populaire. Donc je ne pense pas que cette solution soit viable même en tant que solution temporaire du côté PSA.


Automobile Propre

Automobile Propre est un site d'information communautaire qui est dédié à tout ce qui concerne l'automobile et l'environnement. Les thématiques les plus populaires de notre blog auto sont la voiture électrique et les hybrides, mais nous abordons également la voiture GNV / GPL, les auto à l'hydrogène, les apects politiques et environnementaux liés à l'automobile. Les internautes sont invités à réagir aux articles du blog dans les commentaires, mais également dans les différents forums qui sont mis à leur dispositon. Le plus populaire d'entre eux est certainement le forum voiture électrique qui centralise les discussions relatives à l'arrivée de ces nouveaux véhicules. Un lexique centralise les définitions des principaux mots techniques utilisés sur le blog, tandis qu'une base de données des voitures (commercialisées ou non) recense les voitures électriques et hybrides.

×
×
  • Créer...