Blog LFZ

Changement d'infrastructure serveur ???

johann — 2025-10-27T17:51:54Z

L'idée de derrière tout ceci :

Je suis les vidéos YouTube de Raynox, dont l'infrastructure domotique ressemble beaucoup à la mienne, tout comme la logique qui nous a amené à ce type d'architecture. L'une de ses vidéos a particulièrement retenu mon attention : il y expose des arguments pertinents, notamment celui du choix d'exécuter un conteneur Docker à l'intérieur d'une machine virtuelle QEMU/KVM ou d'un conteneur LXC, autrement dit, une virtualisation en deux niveaux.

Intuitivement, on sent bien que cette approche n'est pas optimale.

Dans un second temps, il présente une alternative que je ne connaissais pas : une distribution Fedora intégrant l'interface web Cockpit, qui permet de gérer aussi bien des conteneurs Podman (équivalents de Docker) que des machines virtuelles QEMU/KVM.

J'avais un mini-PC (Ryzen 5 3500U) qui prenait la poussière dans un coin ... et une carte Hailo 8L en PCIe fraîchement commandée. Alors, par curiosité et un peu pour le fun de la bidouille, je me suis dit :

“Allez, voyons ce que ça peut donner !”

1. Installation de Fedora Server

L'installation de Fedora Server ne présente pas de difficulté particulière, même si son installateur peut sembler un peu déroutant lorsqu'on vient plutôt de l'univers Debian ou Manjaro.

Le processus recommande de désactiver le compte root et de créer à la place un compte utilisateur disposant des privilèges sudo, qui servira à l'administration du système.

J'ai opté pour une installation minimaliste de Fedora Server, sans sélectionner d'autres paquets : tout le reste sera ajouté plus tard, selon les besoins.

Le serveur SSH est opérationnel et activé par défaut, tout comme Cockpit, la suite d'administration web intégrée à Fedora.

En fin d'installation, la machine est immédiatement accessible à distance, que ce soit en SSH pour la ligne de commande ou via Cockpit pour la gestion graphique.

Pour identifier l'adresse IP de votre serveur, deux options s'offrent à vous : soit consulter les informations de votre serveur DHCP (par exemple dans l'interface de votre routeur/box), soit vous connecter physiquement (clavier + écran) à la machine et exécuter la commande ip -a

Une fois votre serveur identifié sur le réseau, la première opération est de mettre à jour la machine, en ligne de commande avec sudo dnf upgrade --refresh -y ou à partir de l'interface cockpit.

Les outils logiciels pour la gestion des containers Podman et des machines virtuelles sont installables dans le menu « Outils » / « Applications » de l'interface de Cockpit.

Dans le menu réseau, il est également possible de définir une adresse ipv4 statique et de créer une interface bridge.

⚠️ Gestion d'espace disque sous Fedora (LVM)

Lors d'une installation par défaut de Fedora utilisant le gestionnaire de volumes logiques (LVM), tout l'espace disque disponible n'est pas immédiatement alloué au volume logique racine (/dev/mapper/fedora-root). Pour visualiser l'état en cours df -h

La commande sudo vgs permet pour voir les détails du groupe de volumes et l'espace libre non alloué (Colonne VFree).

Pour l'assigner,en totalité ou en partie à la partition racine, la commande sudo lvextend -r -L+XXX.XXg /dev/mapper/fedora-root est a exécuter, avec XXX.XXg la valeur en Gb, selon la quantité de disque disponible indiqué par la commande vgs

Enfin pour confirmer : df -h

2. Installation de Frigate dans un container Podman

L'un des avantages majeurs de Podman par rapport à Docker est sa capacité à exécuter des conteneurs en mode rootless, c'est-à-dire sans privilèges administrateur. Les conteneurs tournent alors avec les droits d'un simple utilisateur du système, ce qui renforce considérablement la sécurité.

Pour cela, il suffit de créer un utilisateur dédié, ici nommé « frigate », qui sera responsable de l'exécution du conteneur Podman Frigate. Cette création peut se faire aussi bien en ligne de commande qu'à partir de l'interface web Cockpit.

L'utilisateur frigate doit pouvoir accéder au GPU de la machine afin de bénéficier de l'accélération matérielle pour le décodage des flux vidéo.

Sous Linux, les périphériques graphiques /dev/dri/cardX et /dev/dri/renderD128 appartiennent respectivement aux groupes video et render. Il est donc nécessaire d'ajouter notre utilisateur frigate à ces deux groupes afin qu'il puisse y accéder avec les commandes sudo usermod -aG video frigate et sudo usermod -aG render frigate

Le système Fedora est maintenant opérationnel, avec deux comptes bien distincts :

un utilisateur administrateur, disposant des droits sudo pour gérer la machine,
et un utilisateur standard, dédié à l'exécution du conteneur Frigate avec des droits sur le GPU.

Cette distinction est importante, car certaines commandes devront être exécutées par l'un ou l'autre de ces comptes, selon qu'elles concernent la configuration du système hôte ou celle du conteneur.

Il s'agit à présent de mettre en place un conteneur Frigate basique, sans accélération matérielle pour la détection (c'est-à-dire sans module Hailo-8L).

Par défaut, Fedora Server est protégé par un pare-feu actif. Il faut donc autoriser l'accès aux ports utilisés par Frigate, avec le compte administrateur, soit directement depuis l'interface web Cockpit, soit en ligne de commande avec les instructions suivantes :

sudo firewall-cmd --add-port=5000/tcp --permanent sudo firewall-cmd --add-port=8555/tcp --permanent sudo firewall-cmd --add-port=8554/tcp --permanent sudo firewall-cmd --add-port=8554/udp --permanent sudo firewall-cmd --add-port=8555/udp --permanent

Le démarrage du conteneur Frigate, dans un terminal de l'utilisateur standard Frigate, s'effectue à l'aide de la commande suivante :

frigate@localhost:~$ podman run -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='monMotdePasse' ghcr.io/blakeblackshear/frigate:stable ff900b6866c639bd85ac0b183cb3789059c404c93deee2ae051966bfff9fd428 frigate@localhost:~$

Le conteneur démarre correctement, mais le fichier de configuration par défaut de Frigate provoque quelques problèmes dans mon cas.
J'ai donc dû l'adapter à ma configuration, puis effectuer un redémarrage forcé du conteneur depuis l'interface Cockpit pour que les modifications soient prises en compte.

Vitesse du détecteur de frigate avec 2 cameras h264 2k et une détection sur CPU uniquement

Les performances sont pour l'instant modestes, mais l'ajout de l'inférence matérielle pour la détection devrait normalement les améliorer de manière significative.

3. Détails de la commande « podman run »

Je détaille ci-dessous, pour mémoire, la commande de base présentée ci-dessus, accompagnée d'options et d'explications complémentaires, pas toujours évidentes à saisir au premier abord, notamment en ce qui concerne les implications en matière de sécurité.
L'objectif étant de mettre en place un conteneur rootless, il serait dommage de tout compromettre en négligeant ces aspects.

⚙️ Options générales Podman

podman run -d \ --name frigate \ --restart=unless-stopped \ .... ghcr.io/blakeblackshear/frigate:stable

La commande podman run initialise un nouveau conteneur nommé « frigate », en utilisant l'image spécifiée à la fin de la commande. Le conteneur est lancé en mode détaché, c'est-à-dire qu'il s'exécute en arrière-plan comme un démon, et il est configuré pour redémarrer automatiquement, sauf lorsqu'il est arrêté manuellement.

💾 Mémoire et périphériques

L'option --shm-size=256m permet de définir la taille du segment mémoire partagé (/dev/shm), utile au buffering vidéo (FFmpeg et TensorFlow l'utilisent)

L'option --device /dev/dri:/dev/dri permet au conteneur Podman d'accéder directement à la carte graphique de l'hôte, activant ainsi l'accélération matérielle (hardware) pour le traitement vidéo.
Pour que cela fonctionne correctement, l'utilisateur exécutant le conteneur (dans mon cas frigate) doit appartenir aux groupes video et render, afin d'avoir les permissions nécessaires sur les périphériques GPU.

frigate@localhost:~$ ls -al /dev/dri total 0 drwxr-xr-x. 3 root root 100 23 oct. 17:41 . drwxr-xr-x. 20 root root 4040 23 oct. 17:41 .. drwxr-xr-x. 2 root root 80 23 oct. 17:41 by-path crw-rw----. 1 root video 226, 1 23 oct. 17:41 card1 crw-rw-rw-. 1 root render 226, 128 23 oct. 17:41 renderD128 frigate@localhost:~$ sudo usermod -aG render frigate frigate@localhost:~$ sudo usermod -aG video frigate

🔒 Sécurité et permissions

 --group-add keep-groups \ --security-opt label=disable \ --cap-add CAP_PERFMON \ --cap-add SYS_ADMIN \

L'option --group-add keep-groups autorise le conteneur à hériter des groupes secondaires de l'utilisateur hôte.
Cependant, ici, elle est superflue : les périphériques GPU sont explicitement montés via --device /dev/dri:/dev/dri, et l'utilisateur qui lance le conteneur rootless est déjà membre des groupes nécessaires (video et render).
Cette ligne est conservée uniquement à titre informatif.

Sur une distribution Fedora Server, la configuration par défaut de SELinux empêche un conteneur rootless d'accéder aux statistiques du GPU, ce qui génère l'erreur :
Unable to poll intel GPU stats: Failed to initialize PMU! (Operation not permitted).
Les options permettent simplement de contourner cette restriction et d'obtenir l'accès aux statistiques GPU, au prix d'un compromis sur la sécurité.

--security-opt label=disable : Désactive l'isolation SELinux.
--cap-add CAP_PERFMON : Autorise la lecture des compteurs de performance matériels (GPU/CPU). Requis pour la télémétrie GPU (intel_gpu_top, Frigate GPU stats).
--cap-add SYS_ADMIN : Donne un large accès système (quasi root).

Pour mémoire également, l'option --privileged confère au conteneur des privilèges quasi équivalents à ceux du root de l'hôte. Cela permet l'accès direct à tous les périphériques (/dev/dri/*, /dev/video*, etc.), rendant superflue la configuration des groupes pour l'accès GPU.

En environnement de production, l'accès aux statistiques du GPU n'étant pas vital, il est conseillé de retirer ces options afin de réduire les risques et renforcer la sécurité.

📂 Volumes et répertoires montés

-v /etc/localtime:/etc/localtime:ro	. -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z

Ces options sont classiques sous Docker ou Podman et permettent de partager certains fichiers ou volumes entre l'hôte et le conteneur.
Il faut toutefois prêter une attention particulière au montage des volumes : l'ajout de l'option :z est nécessaire sous SELinux afin d'ajuster automatiquement le contexte de sécurité et permettre l'accès aux données par le conteneur.

--tmpfs /tmp/cache:size=1000000000,mode=1777
Cette option créee un Ramdisk temporaire en mémoire vive (≈ 1 Go) pour le cache vidéo (plus rapide que le disque), accessible à tous (mode=1777)

🌐 Réseau et ports exposés

 -p 5000:5000 \ -p 1935:1935 \ -p 8554:8554 \ -p 8555:8555/tcp \ -p 8555:8555/udp \

Ces options sont également classiques sous Docker ou Podman et permettent d'exposer les ports de l'interface web de frigate (5000), des flux RTMP(1935) , des flux RTSP restreamés (8554) et des flux WebRTC faible latence (8555 / UDP & TCP)

🌿 Variables d'environnement

-e FRIGATE_RTSP_PASSWORD=''monMotdePasse''

Frigate intègre un serveur RTSP interne qui permet de restreamer les flux vidéo des caméras (par exemple pour les visualiser dans Home Assistant, VLC ou d'autres clients RTSP). La variable d'environnement FRIGATE_RTSP_PASSWORD sert à définir le mot de passe RTSP utilisé pour accéder à ces flux restreamés sur rtsp ://ip_du_serveur:8554/nom_de_camera ?user=frigate&password='monMotdePasse'

4. Hailo 8L / Compilation

Le système logiciel Hailo est une pile d'éléments qui interagissent ensemble.

1️⃣ Pilote PCIe (Kernel Driver) : C'est le module bas niveau qui permet au système d'exploitation (Fedora Server) de voir le périphérique et de communiquer avec lui (lecture/écriture sur le bus PCIe).

2️⃣ Firmware (hailo8_fw.bin) : C'est le microcode qui est chargé sur le Hailo-8L lui-même par le pilote au démarrage. Il gère le fonctionnement interne de la puce.

3️⃣ Runtime HailoRT : C'est la bibliothèque que vos applications utilisent pour envoyer des modèles et des données au périphérique.

Le pilote PCIe (driver), le runtime HailoRT (bibliothèque logicielle) et le firmware du Hailo-8L doivent idéalement être de la même version, cela évite d'avoir à ce poser des questions lorsque cela ne fonctionne pas.

⚙️ Vérification de la détection physique (PCIe)
La commande lspci permet de vérifier la présence de la carte Hailo sur le bus PCI Express :

johann@localhost:~$ lspci -nnk | grep -i hailo 04:00.0 Co-processor [0b40]: Hailo Technologies Ltd. Hailo-8 AI Processor [1e60:2864] (rev 01) Subsystem: Hailo Technologies Ltd. Hailo-8 AI Processor [1e60:2864] Kernel driver in use: hailo Kernel modules: hailo_pci

Si la carte est détectée, une ligne mentionnant l'appareil devrait apparaitre. Les ligne « Kernel driver in use » et « Kernel driver » devraient être vide à ce stade, mais vous voyez un retour car, au moment où j'écris ceci, mon système est opérationnel et le pilote est déjà chargé."

Si rien n'apparaît : La carte n'est pas détectée. Le problème est matériel (mauvaise installation, slot PCIe désactivé/défectueux, ou alimentation, ...).

🔍 Identification de la version du Runtime HailoRT
Comme indiqué précédemment, les trois composants de la pile logicielle Hailo doivent idéalement être de versions compatibles. Le driver s'exécute sur le système hôte, tandis que le runtime et les bibliothèques logicielles fonctionnent à l'intérieur du conteneur Frigate. Une fois le conteneur opérationnel, la commande podman ci-dessus permet de vérifier la version du runtime utilisée par l'image Frigate.

frigate@localhost:~$ podman exec frigate hailortcli --version HailoRT-CLI version 4.21.0

⚙️ Compilation du pilote PCIe (Kernel Driver)

La documentation et les fichiers nécessaires pour la carte Hailo-8L requièrent la création d'un compte développeur sur le site Hailo.ai. Bien qu'un paquet .deb prêt à l'emploi soit fourni pour Ubuntu, aucune solution n'est proposée pour Fedora.
Pour contourner ce problème, je me suis appuyé sur la documentation de Frigate, qui fournit un script (à adapter), permettant de télécharger directement les fichiers depuis le GitHub librement accessible, et les étapes de compilation.

Avec le compte utilisateur administrateur, voici l'ensemble des commandes que j'ai rentré :

sudo dnf install -y gcc make cmake kernel-devel kernel-headers dkms git hailo_version='4.21.0' git clone --depth 1 --branch v${hailo_version} https://github.com/hailo-ai/hailort-drivers.git cd hailort-drivers/linux/pcie sudo make all sudo make install cd ../../ ./download_firmware.sh sudo mkdir /lib/firmware/hailo sudo cp hailo8_fw.4.21.0.bin /lib/firmware/hailo sudo ln -s /lib/firmware/hailo/hailo8_fw.4.21.0.bin /lib/firmware/hailo/hailo8_fw.bin sudo cp ./linux/pcie/51-hailo-udev.rules /etc/udev/rules.d/ sudo udevadm control --reload-rules && sudo udevadm trigger

La règle udev fixe les permissions sur /dev/hailo0 à 0666

cat ./linux/pcie/51-hailo-udev.rules #Change mode rules for Hailo's PCIe driver SUBSYSTEM=='hailo_chardev', MODE='0666'

Et enfin un sudo modprobe hailo_pci, si tout c'est correctement déroulé, entraine avec sudo dmesg le chargement du driver :

[161447.538082] hailo: Init module. driver version 4.21.0 [161447.538197] hailo 0000:04:00.0: Probing on: 1e60:2864... [161447.538205] hailo 0000:04:00.0: Probing: Allocate memory for device extension, 13192 [161447.549591] hailo 0000:04:00.0: Probing: Device enabled [161447.549626] hailo 0000:04:00.0: Probing: mapped bar 0 - 000000007146fbe2 16384 [161447.549639] hailo 0000:04:00.0: Probing: mapped bar 2 - 000000002a9ea0a1 4096 [161447.549650] hailo 0000:04:00.0: Probing: mapped bar 4 - 0000000064a2fabf 16384 [161447.549657] hailo 0000:04:00.0: Probing: Setting max_desc_page_size to 4096, (page_size=4096) [161447.549749] hailo 0000:04:00.0: Probing: Enabled 64 bit dma [161447.549755] hailo 0000:04:00.0: Probing: Using userspace allocated vdma buffers [161447.549761] hailo 0000:04:00.0: Disabling ASPM L0s [161447.549767] hailo 0000:04:00.0: Successfully disabled ASPM L0s [161447.552467] hailo 0000:04:00.0: soft reset finished [161447.552471] hailo 0000:04:00.0: Soft reset done [161447.552475] hailo 0000:04:00.0: Writing file hailo/hailo8_fw.bin [161447.599845] hailo 0000:04:00.0: File hailo/hailo8_fw.bin written successfully [161447.599849] hailo 0000:04:00.0: Writing file hailo/hailo8_board_cfg.bin [161447.599929] hailo 0000:04:00.0: File hailo/hailo8_board_cfg.bin written successfully [161447.599931] hailo 0000:04:00.0: Writing file hailo/hailo8_fw_cfg.bin [161447.599985] hailo 0000:04:00.0: File hailo/hailo8_fw_cfg.bin written successfully [161447.689228] hailo 0000:04:00.0: NNC Firmware loaded successfully [161447.689238] hailo 0000:04:00.0: FW loaded, took 138 ms [161447.700933] hailo 0000:04:00.0: Probing: Added board 1e60-2864, /dev/hailo0

Il faut maintenant adapter la commande de lancement du conteneur Frigate pour qu'elle prenne en compte le nouveau périphérique /dev/hailo0, fraîchement reconnu par le système.

podman run --replace -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/hailo0:/dev/hailo0 --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='monMotdePasse' ghcr.io/blakeblackshear/frigate:stable

La commande hailortcli fw-control identify lancée à l'intérieur du conteneur Frigate retourne l'erreur 13 (Permission denied), indiquant un défaut de permission d'accès au Hailo.

frigate@localhost:~$ podman exec frigate hailortcli fw-control identify [HailoRT] [error] CHECK failed - Failed to open device file /dev/hailo0 with error 13 [HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36) [HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36) [HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36) [HailoRT CLI] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36)

N'ayant pas installé le runtime HailoRT sur l'hôte, il n'est pas possible de tester la commande directement depuis celui-ci.
Cependant, les droits d'accès sur /dev/hailo0 étant corrects et le driver PCIe correctement chargé, SELinux apparaît comme le principal suspect de ce problème.

Dans le terminal utilisateur administrateur :

johann@localhost:~$ sudo ausearch -m AVC -ts recent ---- time->Mon Oct 27 09:46:00 2025 type=AVC msg=audit(1761554760.453:1201): avc: denied { read write } for pid=75883 comm="hailortcli" name="hailo0" dev="devtmpfs" ino=812 scontext=system_u:system_r:container_t:s0:c132,c197 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

Les logs SELinux indique bien un soucis. Je désactive temporairement SELinux :

johann@localhost:~$ getenforce Enforcing johann@localhost:~$ sudo setenforce 0 johann@localhost:~$ getenforce Permissive

Et dans le terminal utilisateur frigate, on relance la commande :

frigate@localhost:~$ podman exec frigate hailortcli fw-control identify Executing on device: 0000:04:00.0 Identifying board Control Protocol Version: 2 Firmware Version: 4.21.0 (release,app,extended context switch buffer) Logger Version: 0 Board Name: Hailo-8 Device Architecture: HAILO8L Serial Number: HLDDxxxxxxxxxxxx Part Number: HMxxxxxxxxxx Product Name: HAILO-8L AI ACC M.2 B+M KEY MODULE EXT TMP

Bingo !!! mais ne pas oublier de rétablir le mode « Enforcing » de SELinux avec sudo setenforce 1

Je ne suis clairement pas un expert de SELinux, loin de là. Heureusement, ChatGPT m'a traduit tout ça dans un langage enfin compréhensible par des êtres humains. 😅

johann@localhost:~$ ls -Z /dev/hailo0 system_u:object_r:device_t:s0 /dev/hailo0

Tout comme Gemini :
Gemini : Ce message de refus (AVC denied) de SELinux est très précis et indique clairement que le contexte de sécurité de votre conteneur (container_t) n'a pas la permission d'accéder en lecture et en écriture (read write) au périphérique Hailo (hailo0), qui a le contexte de périphérique générique (device_t).

5. Hailo 8L / SELinux

Après plusieurs échanges avec les IA et quelques tests, deux solutions se dégagent. Pour ma part, j'ai mis en œuvre avec succès la seconde, basée sur la création d'une politique SELinux spécifique car c'est la solution préconisée par Cockpit dans le menu SELinux de l'interface.

1️⃣ Solution semanage / restorecon

– sudo semanage fcontext -a -t container_file_t '/dev/hailo0'

Ceci établit une règle persistante (une "policy file context") dans la base de données de SELinux.
La règle dit : "Chaque fois que le système rencontre le chemin /dev/hailo0, il doit lui attribuer le type container_file_t."

– sudo restorecon -v /dev/hailo0 :

Ceci est la commande d'exécution. Elle applique immédiatement la règle définie par semanage fcontext.
Elle change le contexte de sécurité actuel du fichier /dev/hailo0 en container_file_t.

La problématique de cette approche est qu'elle autorise tous les conteneurs à faire toutes les opérations (lecture/écriture, etc.) sur /dev/hailo0.

Pour atténuer cette problématique, on peut s'assurer que le périphérique /dev/hailo0 appartient à un groupe spécifique (par exemple, le groupe hailo). L'utilisateur exécutant le conteneur Frigate (en mode rootless) doit ensuite être ajouté à ce même groupe pour hériter des droits d'accès."

Le fichier « /etc/udev/rules.d/51-hailo-udev.rules » serait modifier pour contenir SUBSYSTEM=='hailo_chardev', GROUP='hailo', MODE='0660'

2️⃣ Solution audit2allow

Installation des Outils Nécessaires
sudo dnf install policycoreutils-devel -y
Identification des refus dans les logs
sudo ausearch -m avc | grep hailo
Toutes les tentatives infructueuses devraient s'afficher
Génération d'une règle de politique SELinux
sudo ausearch -m avc -c hailortcli | audit2allow -M hailo
👉 Cela crée deux fichiers dans ton répertoire courant :
- hailo.te → le texte de la règle SELinux
- hailo.pp → le module compilé prêt à être chargé

module hailo 1.0; require { type container_t; type device_t; class chr_file { ioctl open read write }; } #============= container_t ============== #!!!! This avc can be allowed using the boolean 'container_use_devices' allow container_t device_t:chr_file { ioctl read write }; #!!!! This avc is allowed in the current policy allow container_t device_t:chr_file open;

Chargement du module de politique hailo
sudo semodule -i hailo.pp
Cette règle devient persistante entre les redémarrages.
Vérification Finale
sudo semodule -l | grep hailo
Lancez à nouveau dans le terminal utilisateur standard,la commande qui échouait :
podman exec -it frigate hailortcli fw-control identify

Si la politique a été correctement appliquée, la commande devrait maintenant réussir à s'exécuter, et vous verrez les détails de votre carte Hailo-8L. Votre système reste en mode enforcing, garantissant la sécurité pour toutes les autres opérations non liées à votre carte.

5. Podman Frigate / Systemd

Deux approches sont possibles :

Utiliser Quadlet, la méthode recommandée et native pour l'intégration de Podman avec systemd,
ou Employer la méthode dite « classique », désormais considérée comme obsolète mais toujours parfaitement fonctionnelle, via la commande suivante :
podman generate systemd --name frigate --files --new

J'ai mis en oeuvre pour ma part la deuxième solution, voici mon mode opératoire
Dans un terminal de l'utilisateur standard Frigate :

– Lancer le container frigate avec ces options définitives :

podman run --replace -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/hailo0:/dev/hailo0 --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='motDePasse' ghcr.io/blakeblackshear/frigate:stable

– S'assurer du bon fonctionnement de frigate, avec une attention particulière pour l'accélération GPU et NPU Hailo. Les « journaux système » et les « Incateurs systèmes » du menu permettent d'établir rapidement un diagnostique.

– Générer le fichier container-frigate.service avec la commande
podman generate systemd --name frigate --files --new

– Valider le contenu du container-frigate.service : cat container-frigate.service et modifier au besoin

– Créer le répertoire /home/frigate/.config/systemd/user et copier/déplacer le fichier container-frigate.service dans ce répertoire

mkdir -p ~/.config/systemd/user cp ./container-frigate.service ~/.config/systemd/user

– Informer systemd d'une modification des fichiers de configuration : systemctl --user daemon-reload

– Activer le service container frigate :
systemctl --user enable --now container-frigate.service

Dans un terminal de l'utilisateur administrateur :
sudo loginctl enable-linger frigate

Bien que n'ayant pas mis en oeuvre la première solution (Quadlet), le site linuxtricks propose un éclairage très pertinent sur la méthode.

6. Conclusion

Je ne prétends pas maîtriser tous les aspects de Podman et systemd, et il est possible que certaines étapes puissent être améliorées.
Quoi qu'il en soit, mon installation Frigate est opérationnelle, et si ce guide peut aider ne serait-ce qu'un peu, l'objectif est atteint.

Après, on ve na pas se mentir, cela est bien plus complexe que la solution actuelle Proxmox + LXC + Docker.

Géolocalisation et Home assistant

johann — 2025-08-07T20:40:28Z

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.