Accueil > Domotique > Géolocalisation et Home assistant

Géolocalisation et Home assistant

jeudi 7 août 2025, par johann

L’objectif est de géolocaliser une personne à l’aide de son smartphone, puis de transmettre cette information à un serveur domotique (Home Assistant dans mon cas). La position ainsi obtenue permet de déclencher des automatisations spécifiques, comme par exemple l’activation ou la désactivation d’une alarme.

Infrastructures envisageables

Pour atteindre cet objectif, plusieurs solutions techniques peuvent être envisagées :

Utiliser l’application companion de Home Assistant :
Il s’agit de la solution la plus simple à mettre en œuvre, tout en offrant une excellente fiabilité. Toutefois, cette approche présente quelques inconvénients :
- L’utilisateur doit disposer d’un compte avec les droits d’accès au système Home Assistant, ce qui n’est pas toujours pertinent ni souhaitable, notamment pour un utilisateur novice.
- La fréquence des mises à jour de position n’est pas entièrement maîtrisable, ce qui peut limiter la réactivité des automatisations.
- Cette solution restreint l’utilisation à l’écosystème Home Assistant, sauf si l’on met en place dans celui-ci, des actions spécifiques permettant de redistribuer l’information, par exemple via un partage des données de géolocalisation sur un broker MQTT.

Utiliser l’API REST du système domotique :
Cette solution est compatible non seulement avec Home Assistant, mais également avec d’autres plateformes domotiques disposant d’une interface REST, comme Jeedom. Elle présente toutefois certains inconvénients :
- Une complexité technique plus élevée, notamment en raison de la mise en œuvre de mécanismes d’authentification nécessaires pour garantir un niveau minimal de sécurité.
- Une adaptation spécifique à chaque système domotique, les API REST variant d’un système à l’autre.
  Ce point peut néanmoins être vu comme un avantage : il devient possible de cibler plusieurs systèmes en parallèle en envoyant simplement les mêmes données de géolocalisation à différentes interfaces via des requêtes multiples.

Utiliser un broker MQTT :
Il s’agit d’une solution plus universelle, compatible avec tout logiciel prenant en charge le protocole MQTT, tels que Home Assistant, Jeedom ou Node-RED. Elle permet une grande souplesse dans la distribution des données de géolocalisation entre différents systèmes.
Cependant, cette approche implique une mise en œuvre plus complexe. En plus du serveur domotique, il est nécessaire de déployer un broker MQTT, avec toute la configuration associée, notamment en matière de sécurisation.

Il est également possible de combiner ces différentes solutions, afin de tirer parti des avantages de chacune.
Par exemple, l’application compagnon de Home Assistant peut être utilisée en parallèle d’un envoi de données via MQTT ou vers une API REST, permettant ainsi une plus grande flexibilité, une redondance fonctionnelle et une interopérabilité entre plusieurs systèmes domotiques.

Mise en garde

Quelle que soit la solution retenue, le serveur domotique — ou le broker MQTT dans le cas d’une architecture distribuée — doit être accessible depuis Internet.
Cela implique de porter une attention particulière à la sécurité des communications : utilisation de connexions chiffrées (HTTPS/TLS), authentification robuste, et protection des accès.

Il vous appartient de maîtriser parfaitement les implications techniques de cette accès depuis l’Internet, notamment en ce qui concerne :

L’ouverture de ports sur la box Internet,
La mise en place éventuelle d’un reverse proxy sécurisé,
La surveillance des connexions et des tentatives d’intrusion.

En cas de doute, il est vivement conseillé de s’appuyer sur des solutions sécurisées prêtes à l’emploi comme Nabu Casa proposé par l’offre Cloud Home Assistant.

Application mobile Home Assistant companion :

À moins d’avoir un besoin spécifique et/ou d’être l’administrateur de l’instance Home Assistant, il est recommandé de créer un utilisateur dédié à l’utilisation de l’application compagnon.
Cette création se fait via le menu Paramètres > Personnes dans Home Assistant. L’utilisateur ainsi créé devra disposer des droits nécessaires pour se connecter à l’instance

L’installation et la configuration de l’application mobile Companion restent relativement accessibles. Il est nécessaire de renseigner l’adresse externe (accessible depuis Internet) de votre instance Home Assistant, ainsi que les identifiants de l’utilisateur préalablement créé.

L’autorisation d’accès à la localisation doit également être accordée à l’application. Cette étape déclenchera des messages de configuration du système Android relatifs aux droits d’accès à la position.
Il est important de configurer ces permissions en adéquation avec l’objectif recherché (suivi en temps réel, en arrière-plan, etc.), afin d’assurer un fonctionnement fiable des automatisations basées sur la géolocalisation.

Une fois ces étapes terminées et validées, une entité de type device_tracker devrait apparaître automatiquement dans Home Assistant (dans mon exemple device_tracker.portableBlogUser)
Cette entité a un état indiquant le lieu (home, not_home, maison, etc....), et expose plusieurs attributs utiles tels que la latitude, la longitude, la vitesse, la précision de localisation, etc.

Par ailleurs, dans l’application mobile Companion, via le menu Paramètres de l’application > Gérer les capteurs, il est possible d’activer la remontée d’autres données pertinentes comme par exemple le niveau de batterie. Ces informations peuvent présentées un intérêt dans les automatisations pour affiner les scénarios domotiques.

Home Assistant distingue les entités de type device_tracker des entités de type person, même si le « tracker » a été généré via le compte d’un utilisateur donné.
Il est donc nécessaire d’associer manuellement le « tracker » nouvellement créé à une ou plusieurs personnes, afin de permettre à Home Assistant de suivre leur présence de manière cohérente. Pour effectuer cette association :

Connectez-vous en tant qu’administrateur.
Rendez-vous dans le menu Paramètres > Personnes.
Sélectionnez la personne à laquelle vous souhaitez associer le « tracker ».
En bas de la fenêtre, à l’endroit intitulé « Sélectionnez les appareils qui appartiennent à cette personne », choisissez ou saisissez le nom du « tracker »

Une fois cette association réalisée, Home Assistant combinera automatiquement les informations du « tracker » avec l’état de présence de la personne

Nota : Une version de l’application Companion existe également pour les appareils Apple (iOS). N’étant pas familier de cet environnement, je ne peux pas détailler précisément sa configuration. Toutefois, les principes généraux restent similaires : connexion à l’instance Home Assistant via une adresse externe, authentification avec un utilisateur dédié, et autorisation de la géolocalisation afin de permettre les automatisations basées sur la position.

API REST de Home Assistant

L’objectif est d’envoyer les données de géolocalisation directement vers une entité device_tracker de Home Assistant, en utilisant une requête HTTP/HTTPS adressée à son API REST. Pour cela, plusieurs étapes sont nécessaires des deux côtés : côté Home Assistant et côté smartphone.

🔧 Côté Home Assistant :

Vérifier et ajuster la configuration pour autoriser l’accès à l’API REST,
Créer un jeton (token) d’authentification pour le smartphone émetteur,
Créer l’entité device_tracker cible, afin qu’elle puisse être mise à jour depuis une requête externe.

📱 Côté smartphone :

Mettre en place une solution capable de collecter la position GPS,
Transmettre à Home Assistant via une requête HTTP(S)

Côté smartphone, plusieurs applications permettent d’automatiser la récupération et l’envoi de la géolocalisation. Parmi les solutions envisageables : Tasker, Automate, Node-RED (en version mobile), IFTTT, etc.

Pour ma part, j’ai choisi Tasker, principalement pour sa simplicité de mise en œuvre et sa grande flexibilité, même il est nécessaire d’acquérir la version payante. Internet regorge de comparatifs et de tutoriels si vous souhaitez explorer d’autres solutions logicielles que celle présentée ici.

🔧 Vérifier et ajuster la configuration pour autoriser l’accès à l’API REST
Il est important de vérifier le contenu du fichier configuration.yaml de Home Assistant. Dans la plupart des cas, la configuration est déjà correcte si vous avez mis en place un accès externe (autre que via Nabu Casa).

Par exemple, dans mon cas, l’accès est autorisé via un reverse proxy et depuis ma passerelle Internet, ce qui permet aux requêtes entrantes d’atteindre Home Assistant de manière sécurisée.

   http:
     ip_ban_enabled: true
     login_attempts_threshold: 3
     use_x_forwarded_for: true
     trusted_proxies:
       - 192.168.5.240/32   # Reverse Proxy on Local Lan
       - 192.168.5.254/32   # Gateway on Local Lan
       - 172.20.0.0/16      # Depend on HA Docker network

Conseil pour les tests : Il est recommandé de désactiver temporairement l’option ip_ban_enabled durant les phases de configuration et de test. Cela évite un bannissement en cas de tentatives incorrectes. Une fois la solution validée et fonctionnelle, réactivez cette option pour renforcer la sécurité de votre installation.

🔑 Créer un jeton d’accès à longue durée

Pour générer un jeton d’accès (long-live token) :

Cliquez sur votre nom et/ou avatar situé en bas de la barre latérale gauche pour ouvrir le menu Profil.
Rendez-vous dans l’onglet "Sécurité".
En bas de la page, cliquez sur le bouton « Créer un jeton ».
Donnez un nom explicite à votre jeton (par exemple : tasker_gps_tracker) et validez.

⚠️ Important : Copiez et sauvegardez immédiatement le jeton généré. Il ne sera affiché qu’une seule fois. Si vous le perdez, il faudra en générer un nouveau.

Si vous rencontrez des difficultés lors de la mise en œuvre avec Home Assistant, vous pouvez consulter ce tutoriel

🛠️ Création de l’entité device_tracker cible

L’étape de création manuelle de l’entité « device_tracker » via un appel au service « device_tracker.see », comme décrit ci-dessous, n’est pas indispensable.
En effet, lors de la première requête valide émise par le smartphone via l’API REST, si l’entité spécifiée n’existe pas, Home Assistant se chargera automatiquement de la créer.

Il est important de noter que la moindre erreur de syntaxe dans le nom de l’entité (champ dev_id) entraînera la création d’une nouvelle entité incorrecte. Par conséquent, vous risquez de chercher une entité qui n’existe pas, simplement à cause d’une faute de frappe.
C’est pourquoi je préfère, dans ma propre démarche, créer manuellement l’entité « device_tracker » dans Home Assistant avant toute automatisation côté smartphone. Cela présente plusieurs avantages :

Éviter les erreurs de nommage susceptibles de générer des entités fantômes ou incorrectes,
Mieux structurer la configuration en ayant une vue claire sur les entités existantes.

À ce jour, sauf méconnaissance de ma part, Home Assistant ne permet pas de créer directement une entité device_tracker de type gps via un menu ou par une configuration YAML (documentation officielle).

💡 Astuce : Pour forcer la création de l’entité, il est possible de simuler une mise à jour via l’appel du service « device_tracker.see » sur une entité encore inexistante. Dès la première mise à jour reçue, Home Assistant créera automatiquement l’entité si elle n’existe pas encore. Cette méthode n’est pas de moi, mais provient d’un échange sur le forum officiel Home Assistant.

    service: device_tracker.see
     data:
          dev_id: fake_tracker
          gps:
               - 48.67
               - 12.5
          gps_accuracy: 10

L’accès au service « device_tracker.see » se fait par le menu Outils de développement, puis l’onglet Actions. Les valeurs saisies n’ont pour l’instant aucune importance.

📱 Côté smartphone

Pour la suite de cette mise en œuvre, j’utiliserai l’application Tasker sur Android. Avant d’entrer dans les détails, il est important de bien comprendre deux concepts fondamentaux de ce logiciel :

Les Profils : ils définissent les conditions ou déclencheurs (ex. changement de position, niveau de batterie, heure, connexion à un WIFI particulier, etc.). Il peuvent être actifs ou inactifs.
Les Actions : ce sont les tâches exécutées lorsque les conditions d’un profil sont remplies (ex. envoi d’une requête HTTP, affichage de notification, etc.).

Dans un premier temps, pour assurer une mise à jour régulière de la position, il est possible de définir un profil cyclique dans Tasker. Par exemple, un déclenchement toutes les 5 minutes permet un bon compromis entre précision et consommation de batterie.

La création d’un tel profil se fait depuis l’onglet « Profils » de Tasker :

Appuyez sur le bouton « + » pour ajouter un nouveau profil.
Sélectionnez le contexte "Heure".
Définissez :
- Heure de début : 00:00
- Heure de fin : 23:59
- Fréquence : toutes les 5 minutes (ou autre selon vos besoins)
  
  Ce paramétrage permet au profil d’être actif en continu tout au long de la journée, avec une activation toutes les 5 minutes.

Une fois la configuration du profil validée (en appuyant sur la flèche retour en haut à gauche), Tasker vous proposera d’associer une tâche, soit une nouvelle tâche, soit une tâche existante.

Cette tâche sera exécutée automatiquement à chaque fois que le profil devient actif . Pour ma part, j’ai choisi de créer une nouvelle tâche que j’ai nommée « Localisation ». Bien entendu, ces valeurs sont à adapter selon votre propre scénario.

Ce profil s’activera brièvement à l’intervalle spécifié. Lorsqu’il est actif, l’action associée « Localisation » aura pour rôle de :

Acquérir la position GPS actuelle du smartphone (latitude, longitude),
Formater ces données dans un un payload JSON,
Envoyer une requête HTTPS/POST sur l’API REST Home Assistant, en incluant le token d’accès préalablement généré.

    Task: Localisation
    A1: Get Location v2 [
         Timeout (Seconds): 30 ]
    A2: HTTP Request [
         Method: POST
         URL: https://IP_EXTERNE_HA/api/services/device_tracker/see
         Headers: Authorization:Bearer YOUR_TOKEN
                  content-type:application/json
         Body: { "dev_id" : "fake_tracker",
            "gps" : [%gl_latitude, %gl_longitude ],
            "gps_accuracy" : %gl_coordinates_accuracy,
             "battery" : %BATT
         }
         Timeout (Seconds): 30
         Automatically Follow Redirects: On
         Structure Output (JSON, etc): On
         Continue Task After Error:On ]

À ce stade, la géolocalisation doit être fonctionnelle et les données de position doivent remonter correctement dans Home Assistant. Il reste cependant une étape importante : associer l’entité « device_tracker » à une personne.
Cette opération se fait dans le menu Paramètres > Personnes, comme décrit précédemment dans le paragraphe sur l’application Companion.

💡 Il est tout à fait possible d’associer plusieurs device_tracker à une même personne. Dans mon propre système, l’application Android Home Assistant Companion et une automatisation Tasker personnalisée remontent toutes deux ma position géographique.

Une simple action de localisation toutes les x minutes peut suffire, mais il ne faut pas négliger l’impact de l’usage répété du GPS sur la batterie du smartphone.

Or, dans la vie quotidienne, nous restons souvent longtemps dans des lieux familiers comme le domicile, le travail ou chez des proches. Il est donc pertinent d’exploiter cette stabilité géographique pour optimiser la fréquence des requêtes de géolocalisation, en adaptant le comportement de Tasker selon le contexte.

Tasker permet justement de définir des profils conditionnels, activés par exemple :

la connexion (ou la possibilité de connexion) à un réseau Wi-Fi spécifique,
la détection de certaines antennes relais GSM (cell tower),
ou d’autres critères contextuels.

Dans mon cas, j’ai choisi de me baser uniquement sur la connexion Wi-Fi. Cela me permet de désactiver la géolocalisation par GPS lorsque le téléphone est connecté à mon réseau domestique ou professionnel, réduisant ainsi l’usage de la batterie sans perte de précision dans les scénarios d’automatisation.

Pour créer un profil Tasker qui ne s’active que lorsque le téléphone est connecté à un réseau Wi-Fi spécifique (comme votre Wi-Fi domestique).

Accédez à l’onglet “Profils” dans Tasker.
Appuyez sur le bouton « + » pour créer un nouveau profil.
Choisissez le contexte suivant : État → Réseau → WiFi connecté
Saisissez le nom du réseau Wi-Fi (SSID) auquel le profil doit être associé.

Une fois cette étape validée, Tasker vous proposera automatiquement d’associer une tâche à ce profil. Cette tâche s’exécutera lorsque le téléphone se connectera au réseau spécifié.

Vous pouvez également définir une tâche lorsque le profil devient inactif, c’est-à-dire quand le téléphone se déconnecte du Wi-Fi.
Une fois le profil créé, vous pouvez le renommer en appuyant longuement sur son nom. Choisissez un intitulé clair et explicite (ex.  : WiFi Maison connecté) pour faciliter la gestion de vos profils, surtout si vous en avez plusieurs actifs selon différents contextes.

L’idée est désormais d’associer des coordonnées GPS fixes aux lieux connus — c’est-à-dire ceux qui activent un profil spécifique — et de n’utiliser le GPS qu’en l’absence de profil actif. Bien que cette logique puisse être répartie sur plusieurs actions, j’ai choisi de tout centraliser dans la seule tâche « Localisation ».

Tasker permet de tester si un profil est actif à l’aide de l’expression « %PACTIVE ~ *,nom_du_profil,* ». Cette condition vérifie si le profil spécifié figure parmi les profils actuellement actifs, d’ou les *.

Je considère, pour la suite, que deux profils ont été créés et renommés en Wifi_Maison_1 et Wifi_Maison_2. L’action « Localisation » s’articule donc désormais comme suit :

    Task: Localisation
    
    A1: If [ %PACTIVE ~ *,Wifi_Maion_1,* ]
        A2: Variable Set [
             Name: %gpsCoord
             To: [latitude_lieu_1, longitude_lieu_1]
             Structure Output (JSON, etc): On ]
        A3: Variable Set [
             Name: %gpsAccuracy
             To: 20
             Structure Output (JSON, etc): On ]
    A4: Else
        A5: If [ %PACTIVE ~ *,Wifi_Maion_2,* ]
            A6: Variable Set [
                 Name: %gpsCoord
                 To: [latitude_lieu_2, longitude_lieu_2]
                 Structure Output (JSON, etc): On ]
            A7: Variable Set [
                 Name: %gpsAccuracy
                 To: 20
                 Structure Output (JSON, etc): On ]
        A8: Else
            A9: Get Location v2 [
                 Timeout (Seconds): 30 ]
            A10: Variable Set [
                  Name: %gpsCoord
                  To: [%gl_latitude, %gl_longitude ]
                  Structure Output (JSON, etc): On ]
            A11: Variable Set [
                  Name: %gpsAccuracy
                  To: %gl_coordinates_accuracy
                  Structure Output (JSON, etc): On ]
        A12: End If
    A13: End If
    A14: HTTP Request [
          Method: POST
          URL: https://IP_EXTERNE/api/services/device_tracker/see
          Headers: Authorization:Bearer VOTRE_TOKEN_HA
         content-type:application/json
          Body: { "dev_id" : "fake_tracker",
            "gps" : %gpsCoord,
            "gps_accuracy" : %gpsAccuracy,
             "battery" : %BATT
         }
          Timeout (Seconds): 30
          Automatically Follow Redirects: On
          Structure Output (JSON, etc): On
          Continue Task After Error:On ]

💡 Astuce bonus – Localiser automatiquement sa voiture :

Tasker permet de créer un profil actif lorsque le smartphone est connecté en Bluetooth à un appareil spécifique. La majorité des véhicules modernes disposent d’un système multimédia avec une connexion bluetooth.
Ainsi, en utilisant un profil "Bluetooth connecté", il devient possible de suivre la position du véhicule en temps réel :

Lorsque que la connexion est active, la position du smartphone correspond à la position du véhicule.
Et lorsque la connexion Bluetooth est coupée, la dernière position connue correspond très probablement à l’endroit où le véhicule a été stationné.

Cette méthode est particulièrement efficace dans le cas d’un conducteur unique, comme c’est le cas pour moi.

Broker MQTT

Dans le cas de l’utilisation d’un broker MQTT, la solution initiale consisterait à ouvrir ses ports (par exemple 1883 pour MQTT classique, ou 8083/8084 pour WebSocket). Toutefois, cela soulève rapidement des problématiques de sécurité et de chiffrement : un certificat SSL dédié au broker et à Home Assistant serait nécessaire.

Dans mon cas, le certificat est déjà géré par un reverse proxy pour l’ensemble du domaine (certificat wildcard). Il paraît donc plus cohérent et sécurisé de laisser ce reverse proxy prendre en charge toute la couche HTTPS de l’infrastructure.
Dans cette optique, et sachant que faire suivre une websocket MQTT à travers mon reverse proxy étant inaccessible (impossible ou hors de ma compétence), une passerelle HTTP vers MQTT (http2mqtt) s’impose naturellement comme solution : elle permet de conserver un point d’entrée unique, sécurisé, tout en assurant la transmission des données vers le broker interne.

Le serveur http2mqtt est déployé sur une instance Docker. Plusieurs images existent ; pour ma part, j’ai utilisé celles de vsimonaitis/http_to_mqtt et rsteckler/docker-http-mqtt-bridge:v1. Cette solution nécessite, lors de la configuration du conteneur Docker, la création d’un token afin de sécuriser l’accès. Le docker compose ressemble à :

---
services:
  http2mqtt:
    image: vsimonaitis/http_to_mqtt
    container_name: http2mqtt
    environment:
      - AUTH_KEY=VotreTokenHttp2Mqtt
      - MQTT_HOST=mqtt://IP_Interne_LAN_Broker:1883
      - MQTT_USER=username_broker_mqtt
      - MQTT_PASS=mdp_broker_mqtt
      - PGID=1001
    ports:
      - 5000:5000
    restart: unless-stopped

Avec le Docker Compose proposé, le reverse proxy devra rediriger une URL entrante depuis l’internet (par exemple, https://broker.mondomaine.fr) vers l’adresse IP hébergeant le conteneur http2mqtt, sur le port 5000.

Le fonctionnement côté Tasker / smartphone ne change pas fondamentalement, seules l’adresse et la structure des données envoyées diffèrent.

L’adresse vers laquelle la requête POST est envoyée est https://broker.mondomaine.fr/post. Aucun header spécifique n’est requis, bien que le format JSON soit attendu. Veillez cependant à ce que votre reverse proxy transmette correctement la requête, car le chemin /post est indispensable.

La structure des données envoyées inclut le topic MQTT de destination et le token définit précédemment. Son format est le suivant :

{ "topic":"loc/fake_tracker",
  "key"   :"VotreTokenHttp2Mqtt",
  "message":"{\"coordinates\":[latitude,longitude],\"batt\":%BATT}"
}

Côté Home Assistant, il est nécessaire de définir les trackers via la configuration. La documentation officielle présente toutes les options de configuration possibles.

Disposant de nombreux équipements communiquant via MQTT, j’ai dédié un répertoire spécifique dans Home Assistant pour les gérer. Mon fichier configuration.yaml contient ainsi la ligne suivante :

mqtt: !include_dir_list mqtt

ce qui indique que le répertoire mqtt regroupe tous les équipements MQTT non pris en charge directement par l’intégration MQTT.

Dans ce répertoire, un fichier tracker.yaml gère les trackers. Son contenu est le suivant :

       device_tracker:
        - name: "tracker fake_tracker"
          json_attributes_topic: "loc/fake_tracker"
          #state_topic: "loc/fake_trackerForceState"
          unique_id: tracker fake_tracker

L’attribut « state_topic » est optionnel et peut être omis si « json_attributes_topic » contient toutes les informations nécessaires à Home Assistant pour déterminer l’état.

Conclusion

Il est fort probable qu’il existe d’autres solutions ou approches techniques pour atteindre le même objectif. Cet article a pour but de partager la manière dont je l’ai mise en œuvre, et non de présenter la méthode à suivre.