J’avais zappé ton message précedent
- Config Nginx
- Config Duckdns
- Config proxy
- Screenshot routeur avec redirection du port 443 vers HA.
Tu rediriges le port 443 vers 8123. L’erreur, si tant est qu’elle soit unique, se trouve ici.
WAN 443 - > LAN IP-HA:443. ce que ca donne chez moi :
J’ai complété la procédure avec cette information.
Ok j’ai redirigé les port mais Tesla Proxy s’arrete en permanace donc je ne peux pas accéder à l’interface.
Par contre pour les nom de domaine j’ai indiqué :
Duck DNS : teslaxxxxxxxxxxn.duckdns.org
NGINX Home Assistant SSL proxy : core-nginx-proxy
Tesla HTTP Proxy : eqxxxxxxxxxxxxxxxxvv.ui.nabu.casa
Pour le dernier, étant donner que sur le déveloper Tesla je ne peux que y rentrer l’adresse Nabu.
L’adresse Duck DNS est refusée:
Donc je ne sai splus quoi faire…
Nabu casa on oublie. Ca ne fonctionnera pas donc inutile d’essayer ca ne sert a rien.
La clé est elle accessible sur https://tondomaine.duckdns.org/.well-known/appspecific/com.tesla.3p.public-key.pem ? poste un screen, ca doit ressembler à ca :
La cle ne s’affiche pas :
mais j’y accede par un autre moyen
De toute façon, il faut que j’arrive a utiliser une adresse sur le compte développeur… Sans ça je n’irai pas loin après.
Cette dernière est assez incomprehensible…
Problème de clé alors.
mais j’y accede par un autre moyen
Je ne peux pas t’aider la dessus, si tu souhaites avoir une config alternative mieux vaut consulter les discussions sur le repo github, il y aura peut être de quoi solutionner le problème.
De toute façon, il faut que j’arrive a utiliser une adresse sur le compte développeur… Sans ça je n’irai pas loin après.
A nouveau, tant que la clé n’est pas accessible via l’url demandée par le module : https://tesla.duckdns.org/.well-known/appspecific/com.tesla.3p.public-key.pem ca ne sert strictement à rien de chercher à gérer la config coté tesla.
1 « J'aime »
Coucou,
Je tente de comprendre une derniere fois ce qui ne fonctionne pas car effectivement je n’arrive pas à accéder à : https://tesla.duckdns.org/.well-known/appspecific/com.tesla.3p.public-key.pem
1 - DuckDNS : Mon système utilise Nabu Casa pour l’accès extérieur.
Est ce que je dois installer DuckDNS avec une adresse xxxx.duckdns.org ? Ou alors je n’installe pas DDNS ?
2 - Dans NGINX, ayant toujours l’accès avec Nabu Casa, dois je mettre le domaine core-nginx-proxy comme tu l’indique plus haut car toi aussi tu utilise Nabu Casa ? Ou une adresse xxxx.duckdns.org ?
Pour le port ok : 443 => IP HA
3 - Au 1er lancement de Tesla Proxy j’obtiens la capture ci dessous et après la relance de Nginx le module s’arrête systématiquement…
Pour le port ok : 442 => IP HA
4 - Dernier petit truc, je n’avais pas de dossier SSL avec des clés dedans.
J’ai utiliser Let’s Encrypt popur en créer mais avec l’adresse xxxx.duckdns.org :
Il ne pourrait pas y avoir le bazard avec ça ?
5 - Mes redirections des ports :
J’ai utilisé l’adresse IP de mon HA
Mais il y en a 2 (une end0 et une wlan)…
Et sinon après ça, j’abandonne et je vous laisse tranquille… 
Bon beaucoup de bla bla ce matin de ma part (désolé) mais j’ai réussi…
J’ai enfin ma clé via https://******tesla.duckdns.org/.well-known/appspecific/com.tesla.3p.public-key.pem
Ensuite je dois être dans ma semaine boulet…
1 - J’ai réussi à créer un nouveau compte Tesla développeur. 
2 - J’ai ensuite reconfigurer Tesla Proxy, cliqué sur les trois 1er boutons de l’Addon jusqu’a Generate token from URL => Ok
Et la ensuite pas moyen d’enroller une nouvelle key… via l’application
Ça peut aider. Au vu de la config que tu présentes dans ton avant dernier post il est possible que le soucis vienne de la.
1 « J'aime »
@Vladvonvidden 
Merci beaucoup pour ton aide mais cela devient galère de gérer l’accès Nabu et DuckDns, les clés, certificats…
Je laisse tomber pour l’instant en espérant que l’appli officielle refasse surface.
1 « J'aime »
@Vladvonvidden Merci pour ta contribution très utile 
De mon coté, j’ai réussi à faire fonctionner les pre requis duckDNS, NGIX et HTTP Proxy tesla et à accéder au certificat en https
J’ai toutefois une question.
Ma configuration est la suivante :
J’accède à mon HA depuis l’externe via une url HTTPS (https://ha.mondomaine.com). Je ne souhaite pas changer de port public pour HA.
[ROUTEUR] => FORWARD port 443 vers IP NAS => [NAS] => Reverse proxy ha.mondomaine.com vers l’adresse IP de la VM Home assistant port 8123 en http
Le certificat SSL est hébergé sur mon NAS
Si je souhaite faire fonctionner Tesla HTTP Proxy en suivant la méthode officielle, je devais faire un FORWARD du port 443 vers l’IP de la VM home assistant (et ca fonctionne bien), ce qui est en conflit avec ma configuration actuelle. (mon routeur ne peut pas forwarder le trafic HTTPS entrant vers le serveur WEB home assistant via reverse proxy du NAS ET forwarder ce meme trafic vers l’adresse IP de la VM Home assistant port 443).
C’est pour celà que j’essaye (en vain de faire fonctionner la configuration suivante) :
- Accès Web à Home assistant (fonctionnel)
[ROUTEUR] => FORWARD port 443 vers IP NAS => [NAS] => Reverse proxy ha.mondomaine.com vers l’adresse IP de la VM Home assistant port 8123 en http
- Acces au certificat Tesla TTL Proxy (ne fonctionne pas (encore ?))
[ROUTEUR] => FORWARD port 443 vers IP NAS => [NAS] => Reverse proxy tesla.duckdns.org vers l’adresse IP de la VM Home assistant port 443 en https
Celà ne fonctionne pas, car le certificat Duckdns est hébergé sur la VM et non sur le reverse proxy.
Mes questions :
-
est ce que tu penses que c’est possible de faire fonctionner Tesla HTTP Proxy en utilisant un reverse proxy en amont (et garder le port public HTTPS pour home assistant) ?
-
si oui, suis je obligé d’héberger le certificat DuckDNS sur mon reverse proxy (NAS) ?
-
si non, que me conseillerais tu, je ne pense pas etre le seul dans ce cas (home assistant accessible de l’extérieur depuis port standard HTTPS).
Merci et bonne journée
Je suis exactement dans le meme cas que toi avec mon NAS et les redirection mais je n’ai meme pas réussi a faire avec Duckdns …
j’avoue que j’ai déjà passer bcp bcp de temps et pour l’instant je sèche complet… 
alors pour DuckDNS c’est pas très compliqué, si tu suis la procédure tu peux avoir ton nom de domaine et le certificat associé sur ton serveur HA.
je pense qu’on est nombreux dans ce cas, et qu’il faut attendre que cette procédure se simplifie…
Apparemment oui, cette discussion semble être un cas très similaire au tiens et une solution a été trouvée. A noter que l’addon a été màj depuis ce qui devrait encore simplifier les choses. Je ne peux donner d’avis plus éclairé sans me plonger vraiment dedans.
Bonjour,
j’ai été confronté au même problème que toi. A priori le code récupéré pour obtenir l’id du véhicule ne fonctionne pas.
j’ai donc copier/coller en dur mon id véhicule que j’ai trouvé dans les attributs du sensor binary_sensor.nomtesla_online
Bonjour,
Merci pour cette cette doc détaillée.
J’ai enfin… réussi à vérifier la clé publique est accessible… après bien des aventures…
"accept_terms: true" pour DuckDNS passé à false ???
"active: true" pour Nginx passé à false ???
Je coince maintenant à l’étape « 2 Authentifiez-vous avec vos informations d’identification. » de mon compte Tesla. => pas vers une erreur 404 :
Error has occurred
We don’t recognize this redirect_uri. Please use the redirect_uri found in your app details
Reference ID:
Mais cette URL n’est pas acceptée aux étapes 4 puis 5 Cliquez sur « Generate token from URL ».
Réponse : « Invalid code! »
Quelqu’un aurait-il une suggestion pour m’aider à progresser ?
Merci.
My stupid mistake : I did put ad reditrect url « my***tesla duckdns org caallback » with double « a » !
After correction and near 10 mn later I could log on Tesla my HomeAssiatnt is now a recognized apllication on my Tesla account interface !
I try now last step : « Enroll public key in your vehicule »
Bonjour,
je suis tout nouveau sur HA et je n’arrive pas à faire remonter les données de Teslamate vers HA en MQTT.
Teslamate est installé via un docker sur une VM proxmox
Ha est installé sur cette même VM proxmox
apres avoir essuyé tout ce que l’on peut trouver sur le net je me retrouver avec ce docker compose:
services:
teslamate:
image: teslamate/teslamate:latest
restart: always
environment:
- ENCRYPTION_KEY=${TM_ENCRYPTION_KEY}
- DATABASE_USER=${TM_DB_USER}
- DATABASE_PASS=${TM_DB_PASS}
- DATABASE_NAME=${TM_DB_NAME}
- DATABASE_HOST=database
- MQTT_HOST=mosquitto
- VIRTUAL_HOST=${FQDN_TM}
- CHECK_ORIGIN=true
- TZ=${TM_TZ}
- MQTT_HOST=${MQTT_HOST}
- MQTT_PORT=${MQTT_PORT}
- MQTT_USERNAME=${MQTT_USERNAME}
- MQTT_PASSWORD=${MQTT_PASSWORD}
ports:
- 4000:4000
volumes:
- ./import:/opt/app/import
cap_drop:
- all
database:
image: postgres:15
restart: always
environment:
- POSTGRES_USER=teslamate
- POSTGRES_PASSWORD=xxxxxxxxxx
- POSTGRES_DB=teslamate
volumes:
- teslamate-db:/var/lib/postgresql/data
grafana:
image: teslamate/grafana:latest
restart: always
environment:
- DATABASE_USER=teslamate
- DATABASE_PASS=xxxxxxxxxxxx
- DATABASE_NAME=teslamate
- DATABASE_HOST=database
ports:
- 3000:3000
volumes:
- teslamate-grafana-data:/var/lib/grafana
mosquitto:
image: eclipse-mosquitto:2
restart: always
command: mosquitto -c /mosquitto-no-auth.conf
# ports:
# - 1883:1883
volumes:
- mosquitto-conf:/mosquitto/config
- mosquitto-data:/mosquitto/data
volumes:
teslamate-db:
teslamate-grafana-data:
mosquitto-conf:
mosquitto-data:
côté .env
TM_ENCRYPTION_KEY=
TM_DB_USER=teslamate
TM_DB_PASS=xxxxxxxxxxxxxx
TM_DB_NAME=teslamate
FQDN_TM=192.168.5.xx #IP de mon HA
TM_TZ=FR
MQTT_HOST=192.168.5.xx # IP de mon HA
MQTT_PORT=1883
MQTT_USERNAME=mqtt # user mqtt créé dans HA
MQTT_PASSWORD=xxxxxxxxxxxxx # mot de passe user mqtt HA
Dans les log de mosquitto j’ai systématiquement le message suivant:
j’ai regardé via MQTT explorer mais je ne vois rien passer
je précie que j’ai bien accès à Teslamate via le port :4000 et à grafana via le port :3000
Si quelqu’un pouvais m’aider, je suis arrivé au bout de mes recherches… 
« Le succès n’est pas final, l’échec n’est pas fatal… » 
Après une re-fresh install de Teslamate celà fonctionne !!
je partage mon docker-compose.yml pour ceux qui rencontreraient le même soucis que moi car le fichier source nécessite quelques modifications pour permettre la remontée d’info vers HA ( il se peut qu’il ne soit pas optimal mais ca fonctionne donc je ne cherche pas plus loin…)
services:
teslamate:
image: teslamate/teslamate:latest
restart: always
environment:
- ENCRYPTION_KEY= # clef d'encryptage
- DATABASE_USER=teslamate
- DATABASE_PASS=#mot de passe
- DATABASE_NAME=teslamate
- DATABASE_HOST=database
- MQTT_HOST= # IP de votre HA
- MQTT_PORT=1883
- VIRTUAL_HOST=# IP de votre HA
- MQTT_USERNAME= #user mqtt créé sous HA
- MQTT_PASSWORD= # mot de passe user créé sous HA
ports:
- 4000:4000
volumes:
- ./import:/opt/app/import
cap_drop:
- all
database:
image: postgres:15
restart: always
environment:
- POSTGRES_USER=teslamate
- POSTGRES_PASSWORD=#mot de passe
- POSTGRES_DB=teslamate
volumes:
- teslamate-db:/var/lib/postgresql/data
grafana:
image: teslamate/grafana:latest
restart: always
environment:
- DATABASE_USER=teslamate
- DATABASE_PASS= # mot de passe
- DATABASE_NAME=teslamate
- DATABASE_HOST=database
ports:
- 3000:3000
volumes:
- teslamate-grafana-data:/var/lib/grafana
volumes:
teslamate-db:
teslamate-grafana-data:
quelques note pour les ultra-novices comme moi :
1/ malgré un docker compose V2 , le fichier a crée doit bien être nommé docker-compose.yml ( ie: avec le tiret au milieu)
2/ pour créé le fichier docker compose j’ai effectué les manip suivantes:
- taper nano docker-compose.yml dans la console du docker
- copier coller les données en modifiant les champs mot de passe et IP host MQTT
- CTRL + O pour valider l’écriture du fichier
-CTRL+X pour sortir - docker compose pull
- docker compose up
côté HA :
-laisser le paramétrage du module externe mosquitto par defaut . Lorsque vous le démarrer , l’intégration MQTT sera automatiquement proposée.
- ajouter votre user/ mot de passe MQTT dans l’integration MQTT ( configurer>re-configurer)
En espérant que cela puisse aider .
Olivier
Il semblerait que ce soit le début de la fin des haricots, comme l’avaient mentionné certains au mois de février.
La limite de 50 requêtes/commandes par véhicule semble se préciser désormais.
Je suis en train de faire des recherches pour envoyer les commandes via BLE plutôt qu’en passant par l’API. Ca semble assez flou pour le moment.
Quelqu’un se serait-il déjà aventuré de ce coté la ? Si oui, serait-il possible de partager un exemple et/ou des ressources à ce sujet ?