Envoyer des commandes à sa Tesla via MQTT/BLE

Merci pour les infos.
j’ai mis l’adresse MAC récupérée via le scanner, sauf que j’ai en boucle (depuis le début, mais j’avais pas renseigné la bonne MAC) :

tesla_ble_mqtt_model_3  | Needs updating for multi-car, only supports TESLA_VIN1 at this time. Doesn't support deprecated TESLA_VIN usage
tesla_ble_mqtt_model_3  | "90:XXXXXXX:B9" presence not detected
tesla_ble_mqtt_model_3  | Listening to MQTT
tesla_ble_mqtt_model_3  | Listening to BLE
tesla_ble_mqtt_model_3  | Needs updating for multi-car, only supports TESLA_VIN1 at this time. Doesn't support deprecated TESLA_VIN usage
tesla_ble_mqtt_model_3  | "90XXXXXX:B9" presence not detected
tesla_ble_mqtt_model_3  | Listening to MQTT
tesla_ble_mqtt_model_3  | Listening to BLE
tesla_ble_mqtt_model_3  | Needs updating for multi-car, only supports TESLA_VIN1 at this time. Doesn't support deprecated TESLA_VIN usage
tesla_ble_mqtt_model_3  | "90xxxxxxB9" presence not detected

Et maintenant je n’ai plus aucune remontée dans HA oO
Dans MQTT Explorer, je n’ai plus qu’un « binary_sensor » qui est à « presence = OFF ».

La première partie du log est normale, j’ai la même chose de mon coté et le message peut être ignoré à l’heure actuelle :

Needs updating for multi-car, only supports TESLA_VIN1 at this time. Doesn't support deprecated TESLA_VIN usage
[CHG] Device A0:-----:38 RSSI: 0xffffffc1 (-63)
A0:-----:38 presence detected
Listening to MQTT
Listening to BLE

Par contre la présence devrait être fonctionnelle.

  1. La voiture est-elle éveillée ? (même si normalement la détection devrait fonctionner en mode veille)
  2. Vérifiez l’addresse MAC BLE de la voiture.

@carmelo42 Hmmm ce log manque de quelques messages par rapport à la dernière version main du repo tesla_ble_mqtt_docker

Quels autres services utilisent le bluetooth sur la machine?
Peux tu lancer bluetoothctl scan on depuis l’image docker?

Je regarde de mon côté. Il y a peut être un bug avec l’image docker qui est disponible sous « latest »

carmelo@teslapi:~/tesla_ble_mqtt_docker/tesla_ble_mqtt_docker $ docker exec -it tesla_ble_mqtt sh
/share/tesla_ble_mqtt # bluetoothctl scan on
SetDiscoveryFilter success
Discovery started
/share/tesla_ble_mqtt #

Bon … je n’y comprends plus rien, mais ça refonctionne désormais …

Par contre j’ai plein de [CHG] Device XXXXXXXX RSSI: 0x...... (-56) dans les logs maintenant ?

[CHG] Device XXXXXXXX RSSI: 0x...... (-56) sont les sorties brutes du scan bluetooth. Ca sera retiré quand tout sera stable.
Je pense que de lancer bluetoothctl scan on puis off a du réinitialiser (ou initialiser) le device… Peut-être.
Tiens moi au courant si tu as d’autres bugs.

C’est super étonnant, parce que j’avais :

  • redémarré le Pi
  • supprimé le conteneur, l’image docker, les volumes, …
  • et on dirait bien effectivement que le bluetoothctl scan on a fait l’affaire …

J’ai l’impression que la connexion se fait bien mieux avec une puce Intel.

Par contre je suis ne suis pas certains de l’adresse mac avec nrf Connect…

C’est bien les derniers chiffres de l’uuid ? Parce que la présence ne fonctionne pas ( inconnu ). J’ai pas trouvé d’adresse mac en clair sur nrf.

Par contre j’ai toujours le soucis des A avec décimales envoyé par l’addon…

Tu utilises nrfConnect sur Android?
Si oui, tu dois avoir plus d’informations. Ce qui est sûr c’est que la MAC n’est pas la fin du UUID (cf image d’exemple prise sur la page de l’appli sur le store)

Ensuite pour l’envoi des A, tu utilises quelle commande?
Directement le slider dans l’entité MQTT?
image

Ou une commande custo dans une automatisation?

Je l’utilise sur iPhone :confused: J’ai essayé d’autres applications mais aucune ne donne les adresses macs. Je vais essayer sans.

Je l’utilise via le blueprint pvexcess, j’ai modifier le fichier de configuration pour passer les step à 1.

C’est bizarre parce que l’entité est bien en step 1 aussi …

Je vais essayer de me faire une automatisation avec l’assistant de HA, ça devrait déjà être mieux de ce côté là :o

Je n’utilise pas PV excess donc je ne peux pas trop t’aider là dessus.
Au pire tu dois pouvoir créer un template number, qui est juste un proxy pour la commande de charge Tesla, en arrondissant à l’entier le plus proche…
Mais oui, en lisant ça, step 1 devrait aider (intuitivement)

Petite question, peut être que quelqu’un aura la réponse, même si pas directement liée à BLE : quand la Tesla dort, pas de remontée des infos dans HA, normal. Par contre, quand je lance la charge via BLE, la voiture se réveille, et se met à charger. Mais je n’ai pas de remontée auto des infos dans HA, je dois cliquer sur « Force data update », et là j’ai bien la remontée d’infos, toutes les 2 minutes comme paramétré dans l’addon Tesla.

Une idée pour ne pas avoir à demander manuellement la 1ère remontée d’info ?

@carmelo42 ça dépend de ton paramétrage de Tesla Custom Integration.
Le « polling » (refresh des données) est périodique, toutes les 11 min chez moi (660sec). Tesla te fournit les infos que si la voiture est éveillée.

Quand tu réveilles la voiture avec BLE, il faudra simplement attendre que Tesla Custom Intégration relance un « polling », donc au maxi dans les 11 prochaines minutes. Tu peux aller plus vite avec « force data update » en effet.

Donc pour répondre à ta question

Une idée pour ne pas avoir à demander manuellement la 1ère remontée d’info ?

→ Attendre

On est également en train de préparer l’ajout de la remontée d’info via BLE (rendue possible récemment par Tesla, mais que sur des trucs simples: lock state, awake, portes ouvertes)

@raphmur merci pour l’explication.
j’ai 2 minutes paramétré dans l’addon Tesla, mais souvent ça ne remonte rien, alors que la voiture est en charge, si je ne fais pas un 1er polling à la main.

je viens de passer le polling sur 5 minutes, voir si ça change quelque chose …

Super nouvelle si des infos remontent par BLE : le moins on s’appuie sur l’API Tesla, le mieux c’est :slight_smile: