Il faut finir la partie des certificat avant de toucher nginx. Je ne vois pas la partie ou tu dois modifier le configuration.yaml pour rajouter le chemin des certificats ssl tu l’as fait?
Ca donne un truc comme:
http:
ssl/xxxxx/ key
ssl/xxxxxx/permission
c’est dans la doc let’s encrypt
alors j’utilise pas let’s encrypt de HA, c’est sur mon NAS que je prend les certificats généré pour mon domaine HA.XXXX.FR
Dans mon http j’ai ça moi
http:
use_x_forwarded_for: true
trusted_proxies: # adresse(s) IP locale(s) du NAS Synology
- 192.168.XX.XX
ip_ban_enabled: no
login_attempts_threshold: 5
en fait j’ai mes 2 fichiers .PEM (fullchain et privkey) que j’ai déjà dans le dossier SSL de HA.
Du coup quand je lance NGUIX, a priori il est lancé et pas d’erreur.
Regardes par là: Intégration Solar Optimizer - Optimisation de sa consommation Solaire - #185 par FuReT
Bonjour @slug74
Je n’arrive pas à exécuter les étapes décrites dans la doc tesla-http-proxy et c’est assez galère.
je suis dans le meme cas que toi, à savoir mon NAS qui gère les certificats pour mon sous domaine home assistant.
Est ce que dans notre cas NGUIX est obligatoire, vu que le NAS fait déjà office de serveur proxy ?
As tu réussi à faire fonctionner tesla-http-proxy ?
La doc du proxy est effectivement très galère. Je rédige une procédure pour clarifier tout cela.
Précision importante : j’utilise mon url nabu-casa pour accéder à HA, je n’avais donc rien configuré en matière de domaine et autres réjouissances avant d’installer le proxy.
Résumé des étapes
tesla.duckdns.org.La documentation complète se trouve ici. En résumé :
domains:
- tesla.duckdns.org
token: <votre_token>
aliases: []
lets_encrypt:
accept_terms: true
algo: secp384r1
certfile: fullchain.pem
keyfile: privkey.pem
seconds: 300
La documentation complète se trouve ici. En résumé :
http:
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24
tesla.duckdns.org. J’utilise volontairement un nom de domaine factice car je n’utilise pas NGinx pour accéder à mon instance HA depuis l’extérieur:domain: core-nginx-proxy
hsts: max-age=31536000; includeSubDomains
certfile: fullchain.pem
keyfile: privkey.pem
cloudflare: false
customize:
active: true
default: nginx_proxy_default*.conf
servers: nginx_proxy/nginx_*.conf
La documentation complète se trouve ici. En résumé :
https://github.com/llamafilm/tesla-http-proxy-addonclient_id: ""
client_secret: ""
domain: tesla.duckdns.org
debug: true
regenerate_auth: false
region: Europe, Middle East, Africa
Depuis l’interface de votre routeur, rediriger le trafic sur le port 443 vers votre instance HA ** sur le port 443 également** (IP du client ou de la VM qui fait tourner). La méthode sera différente pour chacun car elle dépend de l’interface de votre appareil.
Exemple : avec 192.168.1.2 qui fait tourner HA (accessible via le port 8123, rediriger le traffic WAN du port 443 vers 192.168.1.2:443.
A ce stade, vérifier que votre clé publique est accessible a l’addresse https://tesla.duckdns.org/.well-known/appspecific/com.tesla.3p.public-key.pem.
Ne cherchez pas à aller plus loin si vous n’arrivez pas à accéder à la clé à ce stade.
Se rendre sur le site developer.tesla.com. Pour ceux qui seraient inquiet à l’idée de créer un compte la dessus, ca à l’air plutôt ok d’après ce qu’on peut lire sur le github officiel.
Remplir le formulaire avecs les paramètres suivants :
Business Details
Application Access Request
Application Access Request
Application Access Request
Cocher les cases :
A ce stade votre demande sera soumise à Tesla. pour ma part, elle a été immédiatement validée. Vous arrivez alors sur le dashboard developpeur, et pouvez accéder à votre application :
Copier le Client ID et Client Secret :
De retour dans HA, sur la page de configuration du proxy, renseigner le client ID et le client secret.
Redémarrer l’addon. A ce stade, vous devriez pouvoir accéder à l’UI :
Par la suite :
Étapes à répéter sur chaque véhicules :
A venir
T’aurais pas exposé ta clé privée en public des fois ? Le message est trompeur
C’est bien de la clé publique dont il s’agit et non la clé privée, erreur de saisie de ma part. Je corrige.
Voila qui est fait pour le plus gros de la procédure, reste à ajouter la partie sur la configuration de l’intégration mais c’est le plus simple.
J’espère que ca pourra en aider certains. Pour ceux qui utilisaient déjà NGinx pour accéder à leur instance, pensez à laisser votre nom de domaine principal dans la configuration de l’addon.
Une fois la dernière partie ajoutée, je fais une passe grammaire/syntaxe/orthographe et c’est plié.
Gros travail merci beaucoup !
Merci beaucoup pour tout ce boulot !!
Par contre moi je suis toujour bloquer au meme stade avec « 404: Not Found »
J’ai tenté avec ta méthode mais j’ai la meme chose.
J’y ai cru avec la nouvelle version qui traite un cas 404 mais non 
Si je tape juste https://tesla.xxxx.fr j’accès bien a mon HA donc ça redirige bien mais lorsque je tente d’afficher la clé il me met le 404… j’ai l’impression qu’il ne passe pas par NGUIX pour faire la redirection comme écrit dans le fichier de conf alors que j’ai bien mis :
active: true
default: nginx_proxy_default*.conf
servers: nginx_proxy/nginx_*.conf
dans mon conf yaml j’ai bien
http:
use_x_forwarded_for: true
trusted_proxies: # adresse(s) IP locale(s) du NAS Synology
- 192.168.xx.xx
- 172.30.32.0/24
- 172.30.32.3
- 172.30.33.0/24
et que j’ai bien mes fichiers généré par le http proxy tesla :
server {
server_name tesla.xxxxxxx.fr;
ssl_certificate /ssl/fullchain.pem;
ssl_certificate_key /ssl/privkey.pem;
# dhparams file
ssl_dhparam /data/dhparams.pem;
listen 443 ssl http2;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {
return 404;
}
# static public key for Tesla
location /.well-known/appspecific/com.tesla.3p.public-key.pem {
root /share/tesla;
try_files /com.tesla.3p.public-key.pem =404;
}
location = /favicon.ico {
log_not_found off;
}
location = /robots.txt {
log_not_found off;
}
}
si j’essaie de regarder dans le terminale j’arrive bien a lire le fichier avec la clé publique mais la lecture par la redirection ne fonctionne pas, je n’ai plus d’idée, je sais pas si on peut tracer un flux
Merci à tous.
Salut,
Merci pour le partage.
Je suis en train de préparer un article sur l’intégration Tesla pour le site de HACF. Je te contacterai en DM pour cette partie 
J’ai été confronté au même problème. Si tu arrives sur l’écran d’identification HA via l 'url du domaine Tesla, il y a un soucis avec NGinx.
Le domaine Tesla ne doit pas permettre l’accès à l’UI de HA.
Les confs que tu as posté semblent ok, par contre celle de NGinx est incomplète car il n’y a que la partie customization affichée. Pourrais tu la poster entièrement ? En particulier pour vérifier que le domaine spécifié n’est pas celui dédié pour le proxy :
domain: core-nginx-proxy # ⚠ TOUT SAUF LE DOMAINE TESLA
hsts: max-age=31536000; includeSubDomains
certfile: fullchain.pem
keyfile: privkey.pem
cloudflare: false
customize:
active: true
default: nginx_proxy_default*.conf
servers: nginx_proxy/nginx_*.conf
C’est un enfer… Quel est le 
qui nous a inventé ça.
merci @Vladvonvidden pour ce mode opératoire très détaillé ! 
Est ce que l’on est obligés de passer par DuckDNS ? J’ai déjà un nom de domaine avec certificat let’s encrypt, géré directement via le reverse proxy de mon NAS Synology.
Même question pour NGINX, est il indispensable vu que mon NAS gère déjà un reverse proxy ?
Réponse pour DuckDns comme pour Nginx : non ce n’est pas obligatoire. La documentation est claire la dessus.
Le seul pré-requis est le suivant :
Vous devez disposer d’un nom de domaine (FQDN) avec un certificat SSL valide pour héberger votre clé publique sur le port standard 443.
La méthode importe peu, même si l’add-on semble pré-configuré pour un usage avec Nginx SSL proxy. Il y a déjà des exemples de configuration avec des méthodes alternatives, mais impossible pour moi de les tester.
Il y a une discussion sur le repo qui semble être liée à votre cas d’usage, ainsi qu’une autre d’ordre plus général.
en fait, je suis exactement dans ce cas, mon HA est hébergé sur mon NAS Syno et je passe par un reverse proxy (qui porte les certif)
voici la config complète pour NGUIX :
domain: core-nginx-proxy
hsts: max-age=31536000; includeSubDomains
certfile: fullchain.pem
keyfile: privkey.pem
cloudflare: false
customize:
active: true
default: nginx_proxy_default*.conf
servers: nginx_proxy/nginx_*.conf
Je pense que le problème vient du routage car dans le reverse proxy pour accéder a mon HA, je met par exemple : ha.xxxxxxx.fr → IP de la VM + port (8123)
Pour le domaine Tesla, je faisais la meme redirection et j’avais un 404 :
Par contre, si je redirige juste vers l’IP + 443, j’ai l’impression qu’il passe bien par NGUIX mais probleme de SSL …
je pense qu’ensemble on va y arriver 
Mais c’est vrai que c’est bien galère.
Ça ressemble fortement a un problème de routage. Je ne connais pas cette interface mais sur le domaine Tesla, il est fait mention de http et https :
Le protocole de destination peut il être changé en https ?
Ce qui est certain c’est qu’il faut exposer le 443 pour le proxy et non le 8123.
Pour ce que ça vaut il y a des discussions sur l’erreur rencontrée.
bonsoir @slug74
j’ai la meme config que toi (Syno et reverse proxy intégré).
Pour l’instant j’arrive jusque cette étape : visiblement serveur proxy du syno reconnu et paire de clés également… on progresse !
Demain, je regarderai les astuces mentionnées dans cet article : Read this before asking for help · llamafilm/tesla-http-proxy-addon Wiki · GitHub
