Le 26/11/2019 à 22:13, TomaGo a dit :

La base de données est prête pour recevoir le cout de charge depuis la version 1.13.1 - 2019-11-26 mais les informations ne s'affichent pas encore, cela ne devrait pas tarder.

je trouve pas où mettre le prix du kwh

Il y a 6 heures, mrk a dit :

je trouve pas où mettre le prix du kwh

C'est lié au geofencing. Tu le trouves dans les caractéristiques du lieu défini.

Il y a 10 heures, etienne33 a dit :

C'est lié au geofencing. Tu le trouves dans les caractéristiques du lieu défini.

Merci

 

et du coup, tu sais où on renseigne les nouveaux champs :

 

Store more vehicle config attributes (exterior_color, wheel_type, spoiler_type)

 

??

Il y a 6 heures, mrk a dit :

et du coup, tu sais où on renseigne les nouveaux champs :

Nope.

Je pense que c'est récupéré via l'API Tesla mais je ne suis pas allé voir dans le PG si ça y était.

 

Je ne vois même pas ce que l'on peut en faire dans Teslamate.

Le 22/03/2020 à 02:05, mrk a dit :

je trouve pas où mettre le prix du kWh

Dans le dashboard "Charges", tu cliques sur la "location" que tu veux modifier. Ca va ouvir le Géo Fence (sur le port 4000) et tu vas pouvoir y renommer cette "Location" ainsi qu'indiquer un le tarif du kWh à cet endroit.

Par contre ça n'est pas rétroactif, dans mon cas au moins ...

Modifié mars 23, 20206 a par Belokan

Il y a 14 heures, Belokan a dit :

Par contre ça n'est pas rétroactif, dans mon cas au moins ...

moi, j'ai créer le geofence sur la page d'accueil , et il m'a proposé d'appliquer le tarif rétroactivement

Hello

Comme j'ai un peu galéré pour mettre à jour Teslamate (Mac/NAS Synology+Docker)

Ouvrir terminal sur le mac :

• ssh user@ip_du_NAS
     saisir ensuite le password
  sudo su
     saisir ensuite le password
  cd/volume1/@docker
  docker-compose pull
  docker-compose up

   

Il y a 11 heures, gregdo78 a dit :

mettre à jour Teslamate (Mac/NAS Synology+Docker)

tu peux tout faire depuis l'interface de docker sur le syno

 

tu coupes les vm

tu telecharges les images a jour via le registry

tu clear les vm

et tu relances

Mesamdes, Messieurs,

L'un de vous possèderait domoticz et aurait déjà tenté de récupérer des infos via MQTT ?

Je suis actuellement sous cette solution de domotique et j'aurai adoré pouvoir récupérer des infos de teslamate (notamment la position de la voiture, la mienne ayant été livrée avec le homelink désactivé j'aurai pu faire ouvrir le garage en arrivant).

Donc si l'un de vous a déjà pu commencer le travail, ce serait top !

Sinon, ben je vais devoir apprendre comment fonctionne MQTT sur domoticz...

TeslaMate également installé hier pour ma part dans une VM sur une Freebox Delta

J'ai pas mal hésité à mettre le truc sur un VPS quelconque mais bon si le but est d'éviter que ce soit sur le net à l'image de TeslaFi (que j'ai testé le soir ou j'ai eu la voiture donc lundi :p), c'est forcément à la maison

La VM dans la Freebox est temporaire en attendant que je remplace un disque de mon NAS qui a rendu l'âme donc qui reste éteint pour l'instant, ceci dit j'ai mis en place un backup 2x dans la journée sur mon kDrive Infomaniak (que je conseille d'ailleurs si vous voulez évitez d'utiliser un drive des GAFAM type Gdrive /HS), juste au cas où !

 

Il semble y avoir moins de détail que dans TeslaFi qui est plus brut (et moche), ceci dit je pense que le polling est le même concernant l'API Tesla du coup les données brutes sont probablement les mêmes dans la base postgres, je ferais une comparaison et créérait de nouveau dashboards dans Grafana si il me manque des trucs je pense.

 

Par curiosité ceux qui ont ce poller ou un autre, votre voiture alterne souvent aussi entre online/offline lorsqu'elle est réveillée ? La mienne capte plutôt bien le wifi donc je ne pense pas que la connexion fasse défaut.

J'avais le même comportement sur Teslafi avec des timeouts assez réguliers dans les call API, serait-ce côté serveur Tesla que ça pêche un peu ?

Le 25/03/2020 à 11:09, ppbering a dit :

Mesamdes, Messieurs,

L'un de vous possèderait domoticz et aurait déjà tenté de récupérer des infos via MQTT ?

Je suis actuellement sous cette solution de domotique et j'aurai adoré pouvoir récupérer des infos de teslamate (notamment la position de la voiture, la mienne ayant été livrée avec le homelink désactivé j'aurai pu faire ouvrir le garage en arrivant).

Donc si l'un de vous a déjà pu commencer le travail, ce serait top !

Sinon, ben je vais devoir apprendre comment fonctionne MQTT sur domoticz...

Je n'utilise plus domoticz, par contre j'utilise quotidiennement MQTT avec jeedom:

- j'utilise le geofence pour déterminer si la voiture est chez moi ou au boulot

- j'utilise si la voiture est connecter pour déverrouiller automatiquement la prise avant de partir

Ça marche top.

il y a une heure, Chicken a dit :

- j'utilise si la voiture est connecter pour déverrouiller automatiquement la prise avant de partir

Tiens, ça ca m'interesse. C'est casse pied de rentrer dans la voiture le matin pour déverrouiller le cable.

Question idiote : quand tu demandes un déverrouillage, est-ce qu'il y a un timeout qui reverrouille la prise au bout d'un certain temps?

il y a 24 minutes, MattKirby a dit :

Question idiote : quand tu demandes un déverrouillage, est-ce qu'il y a un timeout qui reverrouille la prise au bout d'un certain temps?

Bonne question, je ne sais pas , je testerai.

J'ai simplement un scénario qui ouvre le portail du garage + allume le chauffage dans la voiture (si j'ai pas lancé le préconditionnement avant) + déverrouille la prise c'est tout bête le tout déclenché via google assistant, c'est très pratique.

Bonjour,

Nouvelle version de teslamate : https://github.com/adriankumpf/teslamate/releases

avec support de l'api en mode streaming

 

Enhancements

Streaming API

As the first and only Tesla logging app out there, TeslaMate now use the Tesla streaming API! This brings the following improvements:

• High precision drive data. Rather than active polling, the streaming API allows for passive consumption of a high frequency data stream with the most important drive data (position, heading, speed, power, elevation etc.).

(...)

• Bluetooth hints are no longer needed! Using the streaming API does not prevent the vehicle from falling asleep, thus enabling continuous monitoring. This allows the car to fall asleep more quickly (no more idle timer) and we don't miss up to 21 minutes of driving because of halted polling.

 

j'ai fait la mise à jour, on verra demain en allant au boulot si la précision est plus fine, et comment se comporte la veille.

 

 

Modifié avril 19, 20206 a par bnj04

Super ça ! Je mets à jour de ce pas !

 

Pour résumer un peu pour les non anglophones :

Le poller utilise désormais "l'api streaming" de Tesla plutôt que l'API standard comme les autres pollers ce qui résulte en :

- "Fréquence" bien plus importante de polling car en streaming et donc permanent (et non plus toutes les 30s/1min par exemple), donc meilleur précision concernant les données (position, direction, vitesse, power, altitude...).

- Nouveauté concernant l'altitude qui dépendait des cartes, plus maintenant (quid de ce que ça utilise ? La voiture dispose peut-être d'un baromètre intégré ? Le changelog parle du fonctionnement en tunnels donc pas avec le GPS normalement).

- Plus besoin de gérer les 12/21min de pause dans le polling pour qu'elle s'endort, et plus de loupé au cas ou le poller attendait le dodo mais qu'on partait rouler.

 

Je vais essayer de trouver des infos sur cette fameuse API spéciale, je suis curieux de voir la différence avec l'API standard.

 

Edit : Voilà c'est upgradé, merci docker  A voir maintenant la précision dans les trajets, dommage je suis sorti hier faire des courses va falloir attendre un peu du coup ^^

De ce que je comprends l'API Streaming concernant uniquement la télémetrie de la voiture (speed, odometer, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range, est_range, heading), donc il doit toujours utiliser une partie de l'autre pour avoir des données.

Modifié avril 21, 20206 a par Yann73

Et je ne sais pas pourquoi je peux plus éditer mon dernier message mais concernant l'API streaming de ce que je comprends elle ne concerne que la télémetrie de la voiture (speed, odometer, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range, est_range, heading), donc il doit toujours utiliser une partie de l'autre pour avoir des données.

Donc concrètement ça doit être un truc du genre, en tout cas c'est ce que je ferais ^^ :

- Polling API Streaming (https://streaming.vn.teslamotors.com -> toutes les demi-secondes ou secondes) 24h/24 -> N'influe pas le dodo

- Polling https://owner-api.teslamotors.com/api/1/vehicles pour le refresh du token notamment, qui à l'origine sert à savoir l'état du véhicule (car c'est indépendant du polling direct de la voiture, c'est côté Tesla donc ça ne réveille pas le véhicule) mais le streaming doit faire le taff désormais.

- Si l'API Streaming renvoie des données (drive / charge...) : utilisation de l'API standard pour avoir des infos, et arrêt immédiat dès qu'elle dort car le streaming renvoie plus rien.

Bonjour à tous.

Au risque de passer pour un "branque", mais j'ai tout installé, j'ai saisi mes credentials sur "le port" 4000, et sur le "port 3000" je vois bien apparaître le nom de la voiture.

Ma question est la suivante : pourquoi tout est vide ? aucune donnée ? Alors oui, je n'ai pas roulé depuis, mais il ne récupère pas les infos déjà remontées ?

 

Merci !!!

Bonjour, non, ca se remplira en roulant ou en chargeant

 

J ai pu tester la frequence aujourd hui : 5 points par secondes !

il y a 21 minutes, bnj04 a dit :

J ai pu tester la frequence aujourd hui : 5 points par secondes !

La vache ça enterre la plupart des autres solutions "cloud" que n'avait pu essayé (ils ont peut être évolué depuis)

Hâte de tester cette nouvelle version... pour ma prochaine sortie autorisée. :-(

Merci pour votre retour !

 

Donc si je résume, et pour bien comprendre le fonctionnement.

Teslamate « pool » régulièrement la voiture via les API que Tesla met à sa disposition. Donc en fait, si la base de données est vide, c’est parce qu’il n’y a aucune rétention sur les serveurs Tesla. Il s’agit uniquement de flux temps réels qu’il convient de « capturer » en live. Est-ce exact ?

Donc si c’est capturé en live, comment Teslamate sait que le véhicule est utilisé ? Elle interroge régulièrement les API ? Et dès qu’elle voit du mouvement, son pooling devient de plus en plus pressant ?

Aucun risque sur l’autonomie à l’arrêt du coup ? J’ai constaté que mon véhicule restait bien en veille. Autre possibilité, dès le véhicule se met à rouler, c’est ce dernier qui envoi son statut d’« actif » à Tesla. Teslamate en est informé, et de là commence le pooling...

 

Bref, vous l’aurez compris, j’aimerais vraiment savoir le fonctionnement.... :-)

 

Merci.

@joinman Je t'invite à lire mon message quelques posts plus haut, j'explique le fonctionnement avec la nouvelle API de streaming 

Mais effectivement c'est du temps réel, après je pense que Tesla historise de son côté, mais les calls API ne sont pas exposés ou n'ont pas été trouvés, pour rappel c'est du reverse engineering de l'application qui a permis de dégoter l'API

Modifié avril 22, 20206 a par Yann73

il y a 8 minutes, Yann73 a dit :

@joinman Je t'invite à lire mon message quelques posts plus haut, j'explique le fonctionnement avec la nouvelle API de streaming 

Mais effectivement c'est du temps réel, après je pense que Tesla historise de son côté, mais les calls API ne sont pas exposés ou n'ont pas été trouvés, pour rappel c'est du reverse engineering de l'application qui a permis de dégoter l'API

je les avais bien lus !!!

Mais y a encore des zones d'ombre...

 

Je vais faire un tcpdump sur mon serveur et activer netflow sur mon réseau. Je vais bien voir comment il cause le Teslamate 🤣

 

Je vous tiens au jus.

 

 

Bon, je ne suis pas allé très loin dans mes recherches.

Un petit tour sur mon serveur DNS et voici ce que j'ai vu

Une requête toutes les 30 secondes... je ne pense pas qu'il pool toutes les secondes

 

et le tcpdump (désolé je ne suis pas arrivé à le mettre sous l'image.... 😔)

toutes les 30s. Ce "con" il fait quand même une requête DNS à chaque fois ! (j'ai filtré le tcpdump pour éviter trop d'infos)

Donc en fait, il interroge les serveurs Tesla toutes les 30s, et c'est au niveau des serveurs qui prend l'info la voiture est "up" ou "down". Maintenant il faudrait que je lance une capture quand je roule, pour voir si les échanges s'intensifient ou pas ! Je vais envoyer ma femme chercher du pain, c'est pour la bonne cause 😀

 

09:23:25.319452 IP XXXXXXX.51069 > 205.234.31.120.https: Flags , seq 2374013230, win 64240, options [mss 1460,sackOK,TS val 388561163 ecr 0,nop,wscale 7], length 0
09:23:25.470372 IP 205.234.31.120.https > XXXXXXX.51069: Flags [S.], seq 3733168678, ack 2374013231, win 4380, options [mss 1460,nop,nop,TS val 2697273171 ecr 388561163,sackOK,eol], length 0
09:23:25.470444 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 1, win 64240, options [nop,nop,TS val 388561314 ecr 2697273171], length 0
09:23:25.471805 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [P.], seq 1:221, ack 1, win 64240, options [nop,nop,TS val 388561316 ecr 2697273171], length 220
09:23:25.622339 IP 205.234.31.120.https > XXXXXXX.51069: Flags [.], ack 221, win 4600, options [nop,nop,TS val 2697273323 ecr 388561316], length 0
09:23:25.623415 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 1:4345, ack 221, win 4600, options [nop,nop,TS val 2697273324 ecr 388561316], length 4344
09:23:25.623463 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 4345, win 62264, options [nop,nop,TS val 388561467 ecr 2697273324], length 0
09:23:25.773971 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 4345:4519, ack 221, win 4600, options [nop,nop,TS val 2697273473 ecr 388561467], length 174
09:23:25.774047 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 4519, win 63712, options [nop,nop,TS val 388561618 ecr 2697273473], length 0
09:23:25.776531 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [P.], seq 221:347, ack 4519, win 63712, options [nop,nop,TS val 388561620 ecr 2697273473], length 126
09:23:25.926101 IP 205.234.31.120.https > XXXXXXX.51069: Flags [.], ack 347, win 4726, options [nop,nop,TS val 2697273626 ecr 388561620], length 0
09:23:25.927481 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 4519:4525, ack 347, win 4726, options [nop,nop,TS val 2697273628 ecr 388561620], length 6
09:23:25.927511 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 4525:4570, ack 347, win 4726, options [nop,nop,TS val 2697273628 ecr 388561620], length 45
09:23:25.927608 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 4570, win 63712, options [nop,nop,TS val 388561771 ecr 2697273628], length 0
09:23:25.928074 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [P.], seq 347:611, ack 4570, win 63712, options [nop,nop,TS val 388561772 ecr 2697273628], length 264
09:23:26.077163 IP 205.234.31.120.https > XXXXXXX.51069: Flags [.], ack 611, win 4990, options [nop,nop,TS val 2697273777 ecr 388561772], length 0
09:23:26.100505 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 4570:5645, ack 611, win 4990, options [nop,nop,TS val 2697273801 ecr 388561772], length 1075
09:23:26.144598 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 5645, win 63712, options [nop,nop,TS val 388561988 ecr 2697273801], length 0
09:23:29.433221 IP 205.234.31.120.https > XXXXXXX.33863: Flags [F.], seq 1517268540, ack 1398634600, win 4990, options [nop,nop,TS val 2697277134 ecr 388500320], length 0
09:23:29.433384 IP XXXXXXX.33863 > 205.234.31.120.https: Flags [F.], seq 1, ack 1, win 63712, options [nop,nop,TS val 388565277 ecr 2697277134], length 0
09:23:29.587277 IP 205.234.31.120.https > XXXXXXX.33863: Flags [.], ack 2, win 4990, options [nop,nop,TS val 2697277287 ecr 388565277], length 0
09:23:56.101963 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [P.], seq 611:875, ack 5645, win 63712, options [nop,nop,TS val 388591946 ecr 2697273801], length 264
09:23:56.252922 IP 205.234.31.120.https > XXXXXXX.51069: Flags [.], ack 875, win 5254, options [nop,nop,TS val 2697303953 ecr 388591946], length 0
09:23:56.274297 IP 205.234.31.120.https > XXXXXXX.51069: Flags [P.], seq 5645:6720, ack 875, win 5254, options [nop,nop,TS val 2697303975 ecr 388591946], length 1075
09:23:56.274338 IP XXXXXXX.51069 > 205.234.31.120.https: Flags [.], ack 6720, win 63712, options [nop,nop,TS val 388592118 ecr 2697303975], length 0
09:24:00.269090 IP 205.234.31.120.https > XXXXXXX.37967: Flags [F.], seq 4256118392, ack 3335608583, win 4990, options [nop,nop,TS val 2697307970 ecr 388531156], length 0
09:24:00.269389 IP XXXXXXX.37967 > 205.234.31.120.https: Flags [F.], seq 1, ack 1, win 63712, options [nop,nop,TS val 388596113 ecr 2697307970], length 0
09:24:00.419970 IP 205.234.31.120.https > XXXXXXX.37967: Flags [.], ack 2, win 4990, options [nop,nop,TS val 2697308119 ecr 388596113], length 0

 

Modifié avril 22, 20206 a par joinman

j'ai continué mes investigations...

Alors pourquoi mon serveur DNS ne cache pas longtemps la réponse (max 1 minute)

Tout simplement car le TTL du nom de domaine owner-api.teslamotors.com est à 60s.... Le chiffre en rouge décroit de 1 par seconde. A 0 il repart à 60.

 

#dig A owner-api.teslamotors.com

[...]

owner-api.vn.tesla.services. 1    IN    A    205.234.31.120

 

#dig A owner-api.teslamotors.com

[...]

owner-api.vn.tesla.services. 60    IN    A    205.234.31.120

 

Alors est-ce long ou pas ? Si je compare avec celui de free.fr, vous avez la réponse

#dig A free.fr

[...]

free.fr.        20124    IN    A    212.27.48.10

Je l'ai pris en route, donc je ne connais pas la valeur max. Mais là, l'entrée DNS est encore valide plus de 5h.

 

Donc sachant que l'API interroge toutes les 30s les serveurs Tesla, et qu'en parallèle l'entrée DNS n'est valide que 60s, il n'y a pas trop d'interêt à un mettre en place un DNS local pour cela. Moi je l'ai mais pour d'autres raisons

 

Bonne journée à tous.