Hello @Samuel
sur HomeAssistant, tu dois renseigner les paramètres suivant:
Tu peux désactiver le mode debug a priori
@raphmur merci pour ton retour et ton aide sur le sujet.
J’ai essayé (à mon niveau de compréhension) de configurer cela en suivant tes recommandations.
Le MQTT :
Mais j’ai toujours une connexion refusée :
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[10:07:33] Starting... loading /app/env.sh
[10:07:33] loading libproduct.sh
[10:07:33] NOTICE: Setting up MQTT clients with authentication
[10:07:33] INFO: Configuration Options are:
BLE_CMD_RETRY_DELAY=5
DEBUG=false
MQTT_SERVER=127.0.0.1
MQTT_PORT=1883
MQTT_PASSWORD=Not Shown
MQTT_USERNAME=homeassistant
PRESENCE_DETECTION_LOOP_DELAY=120
PRESENCE_DETECTION_TTL=240
TEMPERATURE_UNIT_FAHRENHEIT=false
VIN_LIST=LRWYGCFXXXXXXX
MAX_CURRENT=25
[10:07:33] INFO: ENABLE_HA_FEATURES=true
[10:07:33] NOTICE: Removing single buttons to be replaced by switches & covers:
[10:07:33] NOTICE: windows, charger, cherge-port, climate, trunk
[10:07:33] NOTICE: delete_legacies_singles; deleting legacy single MQTT entities topics
Connection error: Connection Refused: not authorised.
Error: The connection was refused.
/app/run.sh: line 63: pop_var_context: head of shell_variables not a function context
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
Il y a un truc que je n’ai pas compris / installé. Quand tu parles de MQTT Broker c’est bien lui ou il y a autre chose à installer ?
Oui c’est bien cette intégration qu’il faut utiliser. Tu as bien le module MQTT qui est démarré?
Ensuite, tu as manifestement un problème de login à MQTT, cf. erreur Connection error: Connection Refused: not authorised
Tout es bien configuré?
Normalement, tu as du créer un user MQTT, à utiliser…
Hello,
j’ai exactement le même problème et le meme adaptateur …
Du coup si j’ai bien compris le ticket et la cause c’est le dongle en lui meme, il faut du > à 5 en bluetooth …
ils parlent de celui la du coup : https://www.amazon.fr/dp/B0BVMXLM5P?th=1
C’est bien ça ?
Merci à toi.
Bonjour à tous,
De mon côté j’essaie aussi d’installer cet AddOn qui va être bien pratique pour piloter la charge de la TM3.
Tout à l’air OK de mon côté dans les log concernant l’addon et les commandes apparaissent bien côté MQTT.
Mais côté journaux c’est comme si HA ne voyait pas l’adaptateur bluetooth :
[15:36:32] INFO: Received MQTT message; topic:tesla_ble/LRW3E7FA9MC339xxx/config msg:info-bt-adapter vin:LRW3E7FA9MC339xxx cmd:config
[15:36:32] NOTICE: info-bt-adapter; launching infoBluetoothAdapter(); results in ~10 seconds"
[15:36:32] NOTICE:
# INFO BLUETOOTH ADAPTER
Waiting to connect to bluetoothd...[bluetooth]#
##################################################################
[bluetooth]# version
Version 5.76
[bluetooth]#
Agent registered
[bluetooth]# ##################################################################
[bluetooth]# list
[bluetooth]# ##################################################################
[bluetooth]# mgmt.info
[bluetooth]#
Index list with 0 items
[bluetooth]# ##################################################################
[bluetooth]# show
[bluetooth]# exit
[bluetooth]#
##################################################################
[15:36:32] INFO: Received MQTT message; topic:tesla_ble/LRW3E7FA9MC339xxx/config msg:generate-keys vin:LRW3E7FA9MC339xxx cmd:config
[15:36:32] NOTICE: Generating the private key...
[15:36:32] NOTICE: The private key is shown only in debug mode
[15:36:32] NOTICE: Generating the public key...
read EC key
writing EC key
[15:36:32] NOTICE: -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqU0OsKhaLBWA+8vHPahtWEXGxdIK
NwH77eiIxj7UY5IJ1B0vM6ZmMmAYI2MCXqytHKeO5/LaaPdDGvrpd3jqEQ==
-----END PUBLIC KEY-----
[15:36:32] NOTICE: Adding Home Assistant 'Deploy Key' button
[15:36:33] WARNING: Private and Public keys were generated; Next:
1/ Remove any previously deployed BLE keys from vehicle before deploying this one
2/ Open the Tesla App on your smartphone and make sure the vehicule is awake
3/ In Home Assistant device Tesla_BLE_LRW3E7FA9MC339xxx, push the button 'Deploy Key'
[15:38:04] INFO: vin:LRW3E7FA9MC339xxx presence has expired, set presence OFF
[15:40:03] INFO: Received MQTT message; topic:tesla_ble/LRW3E7FA9MC339xxx/config msg:deploy-key vin:LRW3E7FA9MC339xxx cmd:config
[15:40:03] INFO: Trying to deploy the public key to vin:LRW3E7FA9MC339xxx
[15:40:03] NOTICE: Attempt 1/5 to delivery the public key to vin LRW3E7FA9MC339xxx
[15:40:15] INFO: vin:LRW3E7FA9MC339xxx presence has expired, set presence OFF
[15:40:42] ERROR: teslaCtrlSendKey; Error: failed to find a BLE device: can't init hci: no devices available:
[15:40:42] ERROR: Could not send the key; Is the car awake and sufficiently close to the bluetooth adapter?
En guise de clé bluetooth j’ai flashé un ESP32 en tant que BT Proxy et je suis passé par ESPHome :
Est-ce pour ça ? ou il faut absolument passer par une clé Bluetooth ?
Merci d’avance pour vos conseils 
Tu as qu’un seul device bluetooth sur ta machine home assistant ? Ou plusieurs (même pas forcément déclarés dans ha…)
Car la librairie tesla ble utilisé par défaut le device hci0…
Oui c’est le seul, par contre dans le configuration.yaml je ne vois pas de configuration particulière, il faut le déclarer ?
SInon la machine en question est une VM HAOS hébergée sur un Synology donc pas de bluetooth niveau hardware.
Procédure mise à jour en prenant en compte la dernière version de l’outil.
Salut, j’ai un setup simlaire a toi: je fais tourner HA dans une VM sur synology et une tesla 
.
j’utilise un adaptateur USB connecte au Syno qui est tres proche de l’auto.
Je pense plus ou moins avoir « regle » le problem du bluetooth en avec cette tache planife que je joue chaque heure sur le syno :
sudo virsh detach-device fbb888e0-fe6f-4e3a-b052-9df4e71a12bd /etc/tplink.xml
sudo virsh attach-device fbb888e0-fe6f-4e3a-b052-9df4e71a12bd /etc/tplink.xml
(a adapter a l’id de ta VM)
La detection fonctionne a peu pret a tout les coups, ce qui me fait dire que le probleme lie au device bluetooth est regle.
En revanche l’envoi de commande fonctionne ,aleatoirement, j’ai pas trouve pourquoi.
Bonjour,
Je commence à m’intéresser au pilotage de ma TM3 qui se faisait avant simplement mais qui maintenant est plus complexe avec l’arrivée de la nouvelle API.
Si je comprends bien c’est juste un pilotage en bluetooth de la voiture en faisant passer le RPI pour un téléphone envoyant des commandes ?
Merci pour votre réponse !
Concrètement c’est tout à fait ça.
Merci pour la réponse, c’est top ça !
Avec mon serveur qui se situe à proximité j’aurais juste à avoir une dongle BT et hop.
Merci
Voir réponse de [Vladvonvidden]
Bonjour à toutes et à tous.
Pour ceux que ça peut intéresser, j’ai fait un tuto (pour les noobs comme moi) pour utiliser un ESP32 et ESPhome pour envoyer les commandes à la Tesla :
Mais je me demande si je n’aurais pas dû plutôt passer par l’intégration (je l’avais installée mais mon RPI était trop loin de la voiture) et utiliser le ESP32 juste pour rapprocher le signal BLE…
Avec cette intégration, il est possible de descendre entre 0A et 5A (ce qui n’est pas possible avec la solution ESPhome) ?
Bonjour,
Les demandes sont transmises en bluetooth une par une en dépilant le stock d’appels en attentes générant parfois une longue queue de requêtes si un script (mal fait) a un peu chargé la mule par exemple le changement dynamique d’ampérage de la recharge de la voiture en fonction de la consommation électrique relevée, dont finalement seule la dernière demande reçue est pertinente, transmettre toutes les autres intermédiaires et en retard n’a plus aucun intérêt.
J’ai un script qui adapte l’ampérage de la recharge en fonction des consommations effectives relevées sur le reste de la maison et de l’abonnement souscrit. Le déclencheur est la variation de la consommation relevée, donc assez fréquent finalement, le Shelly transmettant souvent cette information. Ceci a pour corollaire de faire que mon script envoie plus de requêtes que ce que le bluetooth n’arrive à transmettre dans un temps donné via MQTTE/BLE. Une fois le script arrêté, j’ai toujours des mises à jour de puissance qui sont transmises par MQTT/BLE le temps de dépiler les stocks.
Je vais retravailler mon script pour limiter le nombre de requêtes par unité de temps, mais est-il possible soit dans le broker MQTT, soit dans le programme MQTT/BLE de ne tenir compte que de la dernière demande reçue pour un item et non de dépiler toutes les demandes en attentes ? (l’effet, ça n’imprime pas, je relance l’impression jusqu’au moment où je mets du papier et me trouver avec 5 copies inutiles)
Voilà, si quelqu’un a des idées je suis preneur et oui je sais que le coupable est mon script, inutile de me répondre que je ne dois pas envoyer toutes les mises à jours, je le sais et quand j’aurais le temps je le retravaillerai dans les limites des automatisations HomeAssistant et sans prendre le risque de laisser le linky disjoncter parce que le script ne tourne que toutes les x secondes pour transmettre un nombre d’ordres limité par unité de temps et ne pas saturer MQTTE/BLE…
Quel est le but premier de ce script : Maintenir l’ampérage au max tout en délestant en fonction du reste de la conso ?
Bonsoir,
Oui, optimiser la consommation électrique sur les plages d’heures creuses, sachant que le chauffage électrique et le chauffe-eau tournent aussi sur ces plages, mais pas sur la totalité de la plage. Du coup, l’idée est de maintenir un niveau de charge limité en début de nuit pour rester dans les limites de l’abonnement actuel et quand le chauffe-eau a terminé ou si le besoin en chauffage est moindre (températures plus clémentes), utiliser le solde pour charger la voiture au mieux.
Entendu. Au niveau des détails techniques :
La consommation pour mon cas d’usage nocturne est sur les plages d’heures creuses et varie en permanence entre 40 et 70% de la capacité souscrite (chauffages, ECS, lave-vaisselle, etc…). L’objectif est d’utiliser le solde pour charger la voiture. MQTT/BLE peut aussi être utilisé pour adapter la charge de la voiture à la production locale d’énergie renouvelable, par défaut très variable.
Définir un seuil fixe pour la recharge de la voiture n’est pas satisfaisant, par moment on serait proche de la limite maxi de la puissance souscrite, à d’autres moments plus de la moitié de la puissance disponible est inutilisée et si c’est de l’énergie issue d’une production solaire par exemple, c’est une énergie perdue.
La consommation est relevée en temps réel par des CT (Shelly) qui transmettent chaque modification constatée de puissance. L’intervalle des mesures transmises à Home Assistant est variable, de quelques secondes à une minute. Le déclenchement du script doit suivre le rythme des mesures, car en cas de dépassement, il faut rapidement délester avant que le compteur Linky ne se déclenche et coupe l’arrivée générale du courant.
Le fonctionnement constaté de MQTT/BLE est de dépiler la liste des consignes à transmettre à la voiture une par une (FIFO). Le temps de transmission, avec parfois des retransmissions nécessaires, fait qu’une nouvelle consigne arrive au broker avant que la ou les précédentes ne soient transmises. Une file d’attente se forme donc assez rapidement et les variations de puissance envoyées à la voiture sont alors décorrélées de la charge actuelle et deviennent absurdes.
Dans mon cas d’usage ici, je n’évoque que l’optimisation de la consommation heures creuses, cependant en journée, j’ai le même souci avec la production des panneaux solaires : les nuages arrivant et repartant rapidement, la production photovoltaïque est très changeante. Le déclenchement d’une bouilloire à eau, d’un micro-ondes, etc… modifie de façon très dynamique la consommation de la maison. Il est donc là aussi nécessaire d’adapter dynamiquement et en temps réel la consigne de changement d’ampérage de charge de la voiture en fonction de la production et la consommation du reste de la maison.
Est-il possible que MQTT/BLE ne transmette à la voiture que la dernière consigne de la pile MQTT et discard les autres ? (en option bien évidement, car ce comportement n’est peut-être pas souhaitable dans d’autres cas d’usage que celui décrit ici)
Est-il possible que MQTT/BLE ne transmette à la voiture que la dernière consigne de la pile MQTT et discard les autres ?
Mon humble avis est que vous focalisez votre attention sur un aspect technique au détriment du problème dans son ensemble.
Si je résume votre problème, l’objectif principal est de ne pas faire disjoncter le compteur pendant la nuit quand la voiture charge et que les autres appareils fonctionnent. J’imagine donc qu’il n’y a pas de délestage prévu sur le circuit qui alimente la borne/prise de recharge du véhicule.
Vous excuserez cet horrible anglicisme, il vous faut je pense une solution de load balancing/management. En clair, un système qui va imposer à votre voiture de limiter la puissance de charge en fonction de la conso actuelle des autres appareils et de la limite définie par votre abonnemment.
Ca tombe bien, ca existe, c’est compatible HA et Tesla et ca fonctionne hyper bien. Le point bonus c’est que sa gère également l’optimisation solaire en journée pour renvoyer le surplus dans le véhicule.
