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.

Domotiser une borne de recharge EV de marque LIDL

johann — 2025-08-01T08:48:29Z

L'enseigne LIDL commercialise, sous la marque « Ultimate Speed », une borne de recharge murale USWB11 dédiée aux véhicules électriques. Cette borne est équipée d'une interface de communication de type série RS485. L'objectif du présent article est de présenter une démarche afin de l'intégrer à au système domotique Home Assistant.

La domotisation de la borne USWB11 a pour double objectif d'optimiser l'autoconsommation en affectant le surplus de production photovoltaïque à la recharge du véhicule électrique, et de limiter la puissance appelée sur le réseau ENEDIS lors d'une recharge en heures creuses, grâce à un seuil de consigne paramétrable.

Mise en garde

La puissance d'une borne de recharge pour véhicule électrique installée par un particulier est limitée à 3,7 kW (16 A). Pour les installations de puissance supérieure, le décret n° 2021-546 du 4 mai 2021, article 15, impose de faire appel à un professionnel disposant de la qualification IRVE (Infrastructure de Recharge de Véhicules Électriques).

L'installation et l'utilisation d'équipements électriques comportent des risques graves, notamment d'incendie et d'électrocution. Il est essentiel de respecter scrupuleusement les normes de sécurité en vigueur et de faire appel à un professionnel qualifié si nécessaire. Ce dernier sera en mesure de vous proposer une borne de recharge intégrant par construction les fonctionnalités décrites dans cet article. Vous êtes seul responsable de vos actions et des conséquences qui en découlent.

Raccordement électrique

En branchement monophasé, la borne LIDL Ultimate Speed USWB11 respecte la limitation évoquée précédemment de 3,7 kW (16 A).
À titre informatif, dans mon cas particulier, la protection est assurée par un interrupteur différentiel de type F, d'une sensibilité de 30 mA et un disjoncteur magnéto-thermique d'un calibre 16A courbe C. Une protection par disjoncteur différentiel est également envisageable (Exemple de produit Legrand 410753)

L'installation est complétée par un contacteur heures creuses (HC) monté en série avec la borne de recharge, ainsi qu'un dispositif de mesure de type Shelly Pro EM-50. Le contacteur heures creuses est commandé via le contact sec intégré au boîtier Shelly Pro EM. Ces deux équipements sont protégés par un disjoncteur C-2A.

Le raccordement entre la borne de recharge et le tableau électrique est réalisé grâce à un câble de type 3G6 (soit en 6 mm²) sur les borniers 30, 33 et 34. L'accès aux points de connexion, visibles sur l'image D, s'effectue en dévissant le panneau arrière de la borne.

Port de communication RS485 : Raccordements & Paramétrage

La documentation de la borne USWB11 précise qu'elle est compatible avec le protocole Modbus et dispose de 3 ports de communication RS485 situés à coté des connexions de puissance, sur le bornier 22.

La configuration des paramètres de la borne s'effectue via 4 roues codeuses situées derrière la trappe repérée 35, sur le côté gauche du boîtier. Le courant maximal de charge peut être réglé à l'aide de la roue codeuse n°42, tandis que les adresses « esclaves » Modbus sont définies via les roues codeuses 41 (Net1/Net2) et 39-40 (Smart Meter Gateway).

On notera également la présence d'un port USB repéré 43 dans le manuel utilisateur.

Les registres Modbus interrogeables sont également documentés dans le manuel utilisateur.

Malgré toutes mes tentatives, je n'ai pas été en mesure de dialoguer directement avec la box depuis un PC, aussi je soupçonnes une implémentation spéciale du protocole. Plutôt que de chercher à tout réinventer, je me suis contenté de suivre les indications disponibles sur le Github de Max Mustermann.

Les connexions de la liaison RS485 étant situées à proximité de l'alimentation en 230 V secteur, il est impératif de les effectuer HORS TENSION, comme pour toute intervention sur des connexions électriques, ceci afin d'éliminer tous risques d'électrocution.

Une fois le panneau arrière refermé et la borne fixée sur son support mural, le paramétrage des roues codeuses situées dans la trappe de gauche peut être réalisé sous tension, en respectant évidemment toutes les précautions d'usage. L'ouverture de la trappe repérée 35 protégeant les roues codeuses est détectée par le switch repéré 38 (image E), ce qui active le mode configuration et un affichage spécifique sur l'écran de la borne. Une photo est présentée ci-dessous.

Cette affichage reprend le courant de réglage de la borne (16A), l'adresse Modbus de la liaison RS485 Net1/2 (esclave n°1), l'adresse Modbus de la liaison RS485 « Smart Meter Gateway » (maître adresse 0), ainsi que d'autres éléments non pertinent ici.

Une fois la trappe de gauche refermée, si la communication échoue, la borne affichera un message d'erreur (Error 19). Cela n'a pas d'impact dans un premier temps, l'installation reste à finaliser.

J'ai configuré ma borne de recharge avec un courant maximal de 16A et j'utilise le port RS485 Net2, avec l'adresse d'esclave définie sur 1.

Communication avec la borne

La communication entre Home Assistant et la borne LIDL se fera via un microcontrôleur ESP32 et une carte d'adaptation RS485. Home Assistant échangera en Wi-Fi avec le microcontrôleur, qui, lui, communiquera en RS485 avec la borne. Plusieurs options sont disponibles pour ces deux composants :

Pour le microcontrôleur, l'ESP32 Wroom Low Power DevKit de uPesy est un choix convenable, et c'est surtout celui que j'avais en stock. D'autres modèles d'Olimex ou Aliexpress seraient également des choix possibles.
La carte d'adaptation permet d'interfacer les signaux série du micro-contrôleur (en 3.3V), vers une liaison différentielle RS485 (en ± 7V). Le Github de Max Mustermannrecommande le modèle Waveshare 4777 RS485 Board (3.3V), mais un modèle avec séparation galvanique également proposé par le fabricant Warehouse, conviendrait aussi. En fonction de la carte choisie, il sera peut-être nécessaire d'adapter le schéma et l'alimentation de celle-ci (3.3V ou 5V).

Pour information, Waveshare propose une documentation claire et complète des deux modèles de carte, ici (modèle non isolé) et ici (modèle isolé).

source : https://github.com/bammab/custom_components_for_esphome/issues/2

Ce schéma ne constitue qu'un exemple, les choix des entrées / sorties sur le micro-contrôleur étant paramétrables depuis l'intégration ESPHome de Home Assistant, tout comme l'adresse Modbus esclave réellement réglée sur la borne de recharge. Les paramètres de la liaison série RS485 sont par contre fixes et imposés par la borne : 8 bits de données, aucune parité, 1 bit de stop, vitesse de la ligne 4800 bits/s.

Pour ma part, j'utilise la version isolée de la carte d'adaptation RS485. Son raccordement est plus simple, se limitant aux connexions RX, TX et aux deux fils d'alimentation.

ESPHome et intégration à Home Assistant

Pour utiliser ESPHome avec Home Assistant, il est nécessaire d'ajouter ESPHome au système. L'installation peut être réalisée en un clic depuis le site officiel du projet ESPHome. Cette opération installe automatiquement l'add-on « ESPHome Device Builder » qui permet une programmation simplifiée — grâce à un fichier de configuration YAML — du micro-contrôleur ESP32 ainsi que l'intégration « ESPHome » qui mettra à disposition les entités Home Assistant créées. Une fois l'installation terminée, il est alors possible de créer un nouvel objet connecté type ESP directement depuis la barre de menu de gauche dans Home Assistant.

Un fichier de configuration de base pour la borne LIDL est disponible sur le Github de Max Mustermann. Il devra être adapté en fonction de votre câblage spécifique et du modèle de votre carte d'adaptation RS485. Le premier téléversement du code vers le micro-contrôleur ESP32 doit être réalisé via un câble USB. Par la suite, les corrections et mises à jour pourront ensuite être réalisées en WIFI. Ci-dessous mon fichier de configuration :

 esphome: name: lidl friendly_name: Lidl esp32: board: esp32dev framework: type: arduino wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot ap: ssid: "LidlHA" password: "*************" external_components: - source: github://bammab/custom_components_for_esphome uart: id: uswb_uart rx_pin: GPIO23 tx_pin: GPIO22 baud_rate: 4800 stop_bits: 1 uswb: id: uswb_controller uart_id: uswb_uart send_wait_time: 200ms address: 2 update_interval: 10s sensor: - platform: uswb id: requested_current uswb_id: uswb_controller name: "USWB11A1 Requested Current" number: - platform: uswb id: allowed_current uswb_id: uswb_controller name: "USWB11A1 Allowed Current" max_current: 16

Cette configuration crée deux entités dans Home Assistant :

Une entité de type sensor (sensor.lidl_uswb11a1_requested_current) qui contient le courant maximal délivrable par la borne (ici 16A) et qui a été réglé précédemment à l'aide de la roue codeuse n°42.
Une entité de type number (number.lidl_uswb11a1_allowed_current), réglable entre 0 et le courant maximal délivrable. Cette entité correspond au courant effectivement délivré par la borne et permet d'ajuster la puissance de charge.

Nota :

Le courant minimal délivré par la borne est de 6A. Bien que l'entité number autorise une valeur comprise entre 0 et 6A, la borne ne délivrera pas de courant en dessous de ce seuil.
Les entités sont renseignée uniquement lorsque la borne est sous tension (ESP32 sous tension). Quand la borne est mise hors tension, les entités deviennent indisponibles après un délai que je n'ai pas encore évalué.

Une fois la partie logicielle fonctionnelle, le message d'erreur éventuel (Error 19) devrait normalement disparaître. Vous pouvez redémarrer la borne en coupant l'alimentation si nécessaire.

J'ai opté pour la fixation de la carte micro-contrôleur et de la carte d'adaptation série à l'aide de colliers Colson, directement dans l'emplacement arrière la borne de recharge. Le micro-contrôleur est alimenté à partir de la prise USB intégrée à la borne (repère 43). Cela nécessite le passage d'un câble USB type A vers USB type C entre l'emplacement arrière (zone puissance et RS485) et l'emplacement latéral gauche (zone des roues codeuses). Cette opération, relativement simple grâce à un passe-fil, doit impérativement être réalisée hors tension.

Mesures et Analyses

Le courant de charge du véhicule est désormais réglable directement depuis Home Assistant. J'ai réalisé quelques essais électriques, à partir des données mesurées par le shelly pro 50 EM pour mon véhicule électrique, une Toyota Bz4X. Les résultats sont les suivants :

Courant« Home Assistant »	Courant mesuré	Puissance de charge	Facteur de puissance
0 A → 6 A	3,73 A	772W	0,9
7 A	4,68 A	1008 W	0,94
8 A	6,16 A	1357 W	0,96
9 A	7,45 A	1666W	0,97
10 A	8,81 A	1984 W	0,98
11 A	9,82 A	2240 W	0,99
12 A	10,84 A	2458 W	0,99
13 A	11,96 A	2711 W	0,99
14 A	12,96 A	2939 W	0,99
15 A	14,01A	3176 W	0,99
16 A	15,03A	3408 W	0,99

L'analyse des points 7 A ; 4.68 A ; 1008 W vs 14 A ; 12.96 A ; 2939 W ou 8 A ; 6.16 A ; 1357 W vs 16 A ; 15.03 A ; 3408 W montre l'absence de linéarité entre la puissance réellement délivrée par la borne de recharge et la consigne de courant dans Home Assistant (number.lidl_uswb11a1_allowed_current).

ChatGPT confirme la forme quadratique de la courbe.

Le pilotage doit s'effectuer en puissance. Toutefois, la conversion de la consigne de puissance en une consigne de courant, nécessitant l'utilisation d'une fonction réciproque, s'avère complexe et peu adaptée à une mise en œuvre dans un environnement domotique. Ainsi, deux approches plus pertinentes peuvent être envisagées :

On observe un écart de puissance moyen d'environ 260 W entre deux points de consigne de courant consécutifs. Les niveaux de puissance étant définis par des paliers discrets, une approche pertinente consisterait à approximer cette caractéristique par une courbe en escalier, avec des paliers de 260 W. Ainsi, pour ajuster la consigne de courant dans Home Assistant, que ce soit à la hausse ou à la baisse il suffit de diviser la puissance allouable par 260, puis d'ajouter le résultat à la consigne de courant actuelle.

Cette approche revient à se faire un modèle discret (numérique) de la courbe, avec une résolution (quantum) de 260 W. La faible résolution, équivalente à une numérisation sur 4 bits, contribue à atténuer les effets de la non-linéarité de la courbe.
La seconde approche consisterait à stocker les points mesurés dans une liste triée. Il suffit alors de rechercher dans cette liste la valeur immédiatement inférieure à la puissance recherchée. L'indice de l'élément trouvé déterminerait alors la nouvelle consigne de courant à appliquer dans Home Assistant. C'est en effet un algorithme classique de « recherche du maximum sous plafond dans une liste triée ».
Au regard du nombre limité de points dans la liste, il est envisageable de traiter cela avec des structures « if / then / else ». Cette approche permet d'utiliser un template dans Home Assistant, évitant ainsi le recours à des solutions plus complexes.
```
 {% set power = states('input_number.simul_puissance_solaire') | float(0) %} {% if power >= 3408 %} 16 {% elif 3408 > power >= 3173 %} 15 {% elif 3173 > power >= 2939 %} 14 {% elif 2939 > power >= 2711 %} 13 {% elif 2711 > power >= 2458 %} 12 {% elif 2458 > power >= 2240 %} 11 {% elif 2240 > power >= 1984 %} 10 {% elif 1984 > power >= 1666 %} 9 {% elif 1666 > power >= 1357 %} 8 {% elif 1357 > power >= 1008 %} 7 {% else %} 6 {% endif %}
```

Une remarque sur ces deux méthodes : La première méthode offre une flexibilité accrue, permettant à la consigne de courant d'être ajustée soit de manière relative (en fonction de son état précédent), soit de manière absolue. En revanche, la seconde méthode est plus rigide, car elle ne permet qu'un positionnement absolu de la consigne de courant.

Tout ce travail pour simplement contrôler le courant de charge peut sembler peu utile en soi. Cependant, les automatisations offertes par Home Assistant permettront d'apporter des améliorations intéressantes à la gestion énergétique .

Avant d'aller plus loin, voici quelques précisions sur mon installation électrique et les éléments déjà intégrés à mon système domotique :

Un contrat de livraison d'énergie électrique Tempo de 6kVA et un compteur Linky, équipé avec un dispositif TIC (TéléInformation Client) en mode standard, qui informe Home Assistant sur :
- La période tarifaire en cours,
- Les consommations pour chacune des périodes,
Deux dispositifs de mesure de type Shelly Pro EM - 50 renvoyant :
- L'état électrique du réseau Enedis (courant, tension, puissance, ...),
- L'état électrique de la borne de recharge EV (courant, tension, puissance, ...),
- L'état électrique de la maison (courant, tension, puissance, ...),
Un onduleur solaire hybride de marque Deye avec batterie, et de l'intégration Solarman sur Home Assistant proposant entre autres :
- L'état de la batterie (SOC, puissance, courant, ...)
- La puissance solaire produite.

Automatisation de la charge EV en « Heures Creuses »

Comme mentionné précédemment, un contrat de fourniture d'électricité Tempo a été souscrit avec une puissance apparente limitée à 6 kVA. L'ajout récent d'un véhicule électrique introduit un risque de dépassement de cette puissance contractuelle, notamment lorsque plusieurs appareils électroménagers ou systèmes énergivores fonctionnent simultanément.

L'objectif de l'automatisation est donc de moduler dynamiquement la puissance délivrée à la borne de recharge, de manière à exploiter au maximum la puissance ENEDIS disponible sans jamais dépasser un seuil de puissance paramétrable.

Voici les relevés pour une puissance Enedis maximale fixée à 5000 W :

En début d'heures creuses (22h00), l'automatisation limite la puissance de la borne électrique pour éviter de dépasser le seuil de 5000 W coté Enedis.
Aux alentours de 1h00 du matin, les gros consommateurs ne nécessitant plus d'énergie, l'automatisation permet à la borne électrique d'atteindre sa puissance maximale.
Le petit pic/creux observé à 4h30 du matin correspond au démarrage du lave-linge.

Pour régler cette automatisation, nous avons besoin de 2 entités :

Une entité de type « input_boolean » qui permet de d'activer ou de désactiver la régulation « heures creuses » (input_boolean.ev_charge_hc)
Une entité de type « input_number » qui permet d'ajuster le seuil de puissance à ne pas dépasser (input_number.ev_threhold_house_max_power). J'ai retenu pour mon cas, un minimun à 1000, un maximum à 5500 et un pas de 100.

Ces entités sont à créer dans l'onglet « Entrées » des menus « paramètres » / « Appareils et services ».

La première solution évoquée dans le paragraphe précédent, « Mesures et Analyses », semble la plus adaptée pour assurer cette régulation, avec ici une quantification à 300 W.

Elle nécessite l'ajout d'une troisième entité (sensor.ev_consigne_courant_hc) de type « template / sensor », chargée de recalculer dynamiquement la consigne de courant de la borne à chaque variation du seuil de puissance ou de la puissance Enedis.

L'ensemble du calcul sera directement intégré dans le code du template au format texte ici

La suite est relativement simple. À chaque mise à jour de l'entité contenant la consigne calculée « sensor.ev_consigne_courant_hc », et si la régulation est activée « input_boolean.ev_charge_hc », la consigne de courant de la borne « number.lidl_uswb11a1_allowed_current » est ajustée en conséquence.

La condition « Si PC-Voiture power est supérieur à 500 » permet simplement de vérifier que le véhicule est bien connecté à la borne et que la charge a commencé. Cette condition est facultative, car un moyen de mesure sur la borne de recharge est alors nécessaire.

De même, la condition « Si Is_Heures_Creuses est dans l'état Activé » est également facultative Je l'ai ajouté pour différencier le fonctionnement en heures creuses de celui basé sur l'excédent solaire. L'information est récupérée depuis le paramètre ltarf de la télé-information du Linky à l'aide du template suivant :

 - binary_sensor : - name : "Is Heures Creuses" unique_id : Is Heures Creuses state : > % set zone_tarif = states('sensor.linky_ltarf') | urlencode | replace("%20", "") % % if zone_tarif == "HCBLEU" or zone_tarif == "HCBLANC" or zone_tarif == "HCROUGE" % True % else % False % endif %

Pour palier d'éventuelles pertes d'événements sur l'entité « sensor.ev_consigne_courant_hc » une synchronisation automatique est effectuée toutes les minutes, garantissant ainsi une mise à jour fiable de la consigne.

Le Yaml de l'automatisation est téléchargeable ici.

Pour le fun, et pour anticiper le fonctionnement de la borne en valorisation solaire, on pourrait envisager la solution n°2 du paragraphe précédent « Mesures et Analyses ». Il est nécessaire de calculer la puissance disponible correspondant à la différence entre le seuil de puissance fixé et la puissance mesurée par Enedis et tenant compte de la puissance actuellement délivrée par la borne. La connaissance de la puissance absorbée/délivrée par la borne, estimée par le réglage en cours ou mesurée, est donc indispensable.
La troisième entité (sensor.ev_consigne_courant_hc) de type « template / sensor » évoquée précédemment pourrait ressembler au code suivant :

Automatisation de la charge de « valorisation solaire »

L'objectif est de prioriser le stockage de l'énergie solaire dans les batteries et, une fois celles-ci chargées au-delà d'un seuil ajustable, rediriger l'excédent vers la borne de recharge afin d'optimiser l'autoconsommation en chargeant mon véhicule électrique. Ce mode de fonctionnement reproduit simplement le mode « smart load » disponible sur un onduleur Deye.

Fonctionnement du mode « valorisation solaire »
La borne de recharge « valorisation solaire » est mise sous tension via le contact sec du Shelly Pro-EM-50 et une entité Home Assistant remontant son statut passe à actif si toutes les conditions suivantes sont remplies :

Le mode « charge solaire » est activé
La batterie est chargée au-delà du seuil haut
L'excédent solaire est suffisant

Afin d'éviter des cycles marche/arrêt intempestifs de la borne, notamment en cas de variations de la production solaire (passage d'un nuage, par exemple), une fois activée dans ce mode, la borne ajustera dynamiquement sa puissance. Elle pourra également puiser dans la batterie de stockage si nécessaire, jusqu'à atteindre un seuil bas prédéfini de celle-ci.

Si la batterie descend en dessous de ce seuil minimal, quelle que soit la production solaire, la borne sera automatiquement mise hors tension afin de préserver le stockage d'énergie ou de permettre sa recharge.

Entités Home Assistant nécessaires à l'automatisation

input_boolean.ev_charge_solaire : Active ou de désactive la régulation solaire
input_boolean.ev_charge_solaire_statut borne : Indique si la borne de recharge est sous ou hors tension.
input_number.ev_charge_solaire_batterie_low : Seuil de batterie bas, ajustable entre 20% et 50%, par pas de 5%
input_number.ev_charge_solaire_batterie_high : Seuil de batterie haut, ajustable entre 50% et 100%, par pas de 5%
input_number.ev_charge_solaire_seuil_puissance : Seuil minimal de puissance solaire qui doit être disponible pour entrer dans le mode, ajustable entre 800W et 2000W, par pas de 100W
sensor.ev_solaire_consigne_courant_charge : de type « template/sensor », cet entité contient la consigne calculée à appliquer à la borne de recharge en mode solaire. Le calcul est réalisé dans le code du template dispo ici.

Nota : j'utilise une entité input_number.simul_puissance_solaire pour simuler la puissance solaire produite et réaliser les tests.

Une entité de suivi du niveau de charge de la batterie est également nécessaire. Dans mon cas, j'utilise sensor.solarman_battery_soc, fournie également par l'intégration Solarman,

Les deux automatisations ci-dessous assurent la mise sous tension et l'arrêt automatique de la borne de recharge en fonction de la production solaire et du niveau de charge de la batterie.

Interface de pilotage sur le dashboard

Le widget propose deux interrupteurs : l'un permet d'activer le mode recharge solaire, l'autre le mode recharge heures creuses. Il intègre également les paramètres de configuration suivants : seuil maximal de puissance appelée sur le réseau ENEDIS, seuil minimal de production solaire requis pour initier la recharge, ainsi que les niveaux de charge minimale et maximale de la batterie du véhicule.

Le graphique associé affiche l'énergie journalière délivrée par la borne au véhicule, sans distinction entre l'origine de l'énergie (solaire ou heures creuses).

Bilan

Ce système est conçu pour évoluer. J'envisage déjà l'ajout d'un mode manuel, permettant de régler directement le courant de charge via le widget déjà présent sur le dashboard Home Assistant.

C'est précisément l'objectif de cette réalisation : adapter finement la recharge de mon véhicule électrique à mes besoins spécifiques, qu'il s'agisse d'optimisation énergétique, de confort d'usage ou de contraintes techniques.

L'idée de fond : Le fun bien sur mais également opérer une transition vers un mode de transport plus sain et plus économique, malgré l'investissement initial. Je conçois bien que tout cela n'est pas à la portée technique de tous, mais des solutions clé en main existent.

Une vidéo intéressante illustrant une borne capable de valoriser sa propre production solaire pour la recharge de véhicule électrique. Attention cependant, il s'agit d'une borne de 7kW qui doit être installé par un professionnel IRVE.

Production solaire et compteur Linky

johann — 2025-07-31T13:24:31Z

L'objectif est de synthétiser les difficultés de télé-relevés rencontrées avec le compteur Linky et une production solaire.

Production photovoltaïque :

L'installation repose sur un onduleur solaire hybride de marque Deye, modèle SG03LP1-EU, qui constitue le cœur du système.

Deux groupes de panneaux solaires assurent la production d'électricité :

6 panneaux solaires de 500 W chacun (Trinasolar TSM-500) sont installés en toiture, reliés en série, puis connectés à l'une des entrées MPPT de l'onduleur hybride.
Le raccordement en courant continu (DC) à l'onduleur hybride permet à ce dernier de suivre et optimiser la production solaire en temps réel, et de la stopper si besoin pour éviter toute injection sur le réseau ENEDIS, dans une logique d'autoconsommation uniquement.

4 panneaux solaires de 500 Wc chacun (DM500M10RT-B60HBT) sont installés au sol.
Ils sont reliés à un micro-onduleur Hypontech (HMS-2000W) doté de 4 entrées MPPT indépendantes, permettant d'optimiser la production de chaque panneau séparément, notamment en cas d'ombrage partiel.
Ce micro-onduleur convertit directement l'énergie solaire en courant alternatif (AC). Il est ensuite raccordé à l'entrée “SmartLoad” de l'onduleur hybride, une entrée spécialement conçue pour accueillir ce type de production AC secondaire, selon un principe de couplage AC.

L'onduleur hybride alimente l'ensemble de l'habitation via sa sortie secourue “Load”, à l'exception des consommations fortement énergivores, comme la borne de recharge pour véhicule électrique (VE), qui est directement raccordée en amont, sur le réseau public ENEDIS.

Grâce aux paramètres de configuration de l'onduleur Deye et à sa pince ampèremétrique, il est toutefois possible de compenser tout ou partie de cette consommation, même si elle n'est pas physiquement connectée à la sortie "Load". Par exemple, lors de la recharge d'un véhicule électrique en journée, l'onduleur injecte automatiquement de l'énergie solaire vers le réseau pour réduire ou compenser la quantité d'électricité qui aurait du être prélevée depuis ENEDIS.

L'installation intègre également un stockage de 15 kWh, assurée par trois batteries Pylontech US5000. Ce stockage permet de stocker le surplus de production solaire de la journée pour une utilisation différée, notamment le soir ou en cas de coupure réseau. Ce stockage peut également être rechargé par le réseau ENEDIS en cas de journée faiblement ensoleillée ou en prévision d'un jour rouge de la tarification EDF Tempo.

Problématique avec le compteur Linky :

A la suite de mon passage à l'option EDF Tempo, mes factures ont été établies sur la base d'estimations, et non plus à partir des télé-relevés automatiques du compteur Linky, comme c'était le cas auparavant.

Dans le cadre d'un changement de contrat, cela ne m'a pas immédiatement inquiété : j'ai supposé qu'un délai de traitement était sans doute nécessaire pour finaliser la transition.

Vient ensuite la période hivernale, avec l'arrivée des premiers jours “blancs” et “rouges”. Je constate alors que si le compteur Linky bascule correctement entre heures pleines et heures creuses, il reste bloqué en “jour bleu”, quel que soit le signal Tempo attendu.

Le site EDF de prévision des jours Tempo affiche bien la couleur du jour en cours (bleu, blanc ou rouge), ce qui confirme en apparence la bonne transmission du signal.
Cependant, il est également précisé que seules les informations affichées sur le compteur Linky font foi contractuellement, les données en ligne n'ayant qu'un caractère purement indicatif.

Seules les informations affichées sur votre compteur sont contractuelles. Les données communiquées sur le site internet le sont à titre indicatif. En effet, pour des raisons techniques, des différences peuvent parfois survenir entre la couleur indiquée et celle réellement pratiquée.

Je contacte alors mon fournisseur d'énergie, qui me met en relation avec ENEDIS, le gestionnaire du réseau électrique. C'est à partir de là que ma découverte commence.

Pulsadis 175 Hz vs CPL CENELEC A :

Historiquement, EDF utilisait un système de télécommande appelé PULSADIS, permettant, depuis les postes de distribution HTA, de déclencher à distance le changement de tarif des compteurs électriques à des horaires prédéfinis.

Le principe reposait sur l'injection d'un signal codé directement dans le réseau électrique, sur une fréquence porteuse à 175 Hz.
Les récepteurs compatibles, intégrés aux compteurs électroniques d'ancienne génération ou à certains équipements, étaient capables de reconnaître ce signal et d'exécuter automatiquement les commutations appropriées : passage en heures pleines/heures creuses, changement de couleur tarifaire Tempo.

Le site de Matthieu Benoit décrit cela avec précision. À noter toutefois que ce site est resté en HTTP non sécurisé, ce qui peut entraîner des avertissements de sécurité sur certains navigateurs.

Avec le déploiement du compteur communicant Linky, le système Pulsadis a été progressivement abandonné, au profit d'un système de communication bidirectionnelle par courant porteur en ligne (CPL).
En France, ce CPL utilise la bande de fréquence “CENELEC A”, qui s'étend de 35.9 kHz et 90.6 kHz. Ce canal permet à Linky d'échanger des données en temps réel avec un concentrateur, aussi bien pour la relève, les changements tarifaires, que pour les commandes à distance. Un concentrateur peut gérer plusieurs centaines de compteurs Linky.

Les compteurs Linky sont organisés en grappes, chacun fonctionnant comme un nœud au sein d'un réseau local (LAN). Ils disposent d'une adresse IPv6, ce qui leur permet d'être identifiés et interconnectés de manière unique sur le réseau CPL.

source : http://stop-linky46.fr/tech/cpl.htm

La liaison entre les concentrateurs Linky et le système de supervision d'ENEDIS s'effectue via une connexion mobile (GPRS/3G/4G), permettant la transmission des données collectées vers le système d'information central.

Lorsqu'un compteur est en communication active avec le concentrateur de quartier, son adresse est dite “associée”. Par ailleurs, les Linky peuvent également jouer un rôle de répéteur : ils sont capables de relayer les données des compteurs Linky voisins situés hors de portée directe du concentrateur, ce qui est particulièrement utile dans des zones peu denses comme la campagne.

Contrairement au système Pulsadis, qui n'émettait des signaux qu'à des heures précises et limitées, le CPL utilisé par les compteurs Linky transmet des “pings” toutes les minutes, 24h/24.
Ce fonctionnement en émission continue est l'un des points de discorde soulevés par les opposants au Linky : les rayonnements électromagnétiques générés par les câbles électriques sur la bande de fréquence utilisée (35.9 kHz et 90.6 kHz), bien que de faible puissance, sont perçus comme présentant des risques sanitaires, le Centre International de Recherche sur le Cancer (CIRC) ayant classé ces rayonnements de basses fréquences dans la catégorie 2B, c'est-à-dire “potentiellement cancérogènes pour l'homme”.

Pourquoi toutes ces précisions ?
Parce que les onduleurs sont des appareils d'électronique de puissance capables de générer différents types de courant, notamment du courant alternatif (AC) à partir d'un courant continu (DC), en utilisant des techniques de découpage à haute fréquence (typiquement 10 à 20 kHz)
Ces opérations produisent également des signaux parasites ou harmoniques sur les lignes électriques, dans des bandes de fréquence proches de celles utilisées par le CPL Linky.
Autant cela ne posait aucun problème avec le système Pulsadis, qui était simple et ponctuel, autant cela devient réellement problématique avec le CPL utilisé par le Linky, dont la communication continue est plus sensible aux perturbations électromagnétiques.

Il faut alors admettre, non sans une certaine ironie, que je suis moi-même à l'origine des perturbations.

Mon propre système solaire, via ses onduleurs et équipements électroniques, interfère avec la communication CPL de mon compteur Linky.

Linky :

source : https://floressas.jimdofree.com/2017/02/12/la-fronde-anti-linky/

Les compteurs Linky existent en deux versions principales : G1 et G3, correspondant à deux générations de technologie, principalement différenciées par leur protocole de communication CPL et donc de leurs capacités de performance.

Les Linky de type G1 exploitent uniquement 2 fréquences de la bande CENELEC-A (63.3 et 74 kHz ) avec une modulation FSK.
Les Linky de type G3 exploitent quant à eux 25 fréquences porteuses entre 35.9 kHz et 90.6 kHz (porteuse 23 à 38 et 50 à 58) avec une modulation OFDM (Orthogonal Frequency Division Multiplexing). Ce choix permet d'atteindre à la fois une meilleure immunité aux perturbations électromagnétiques et un débit de communication plus élevé, garantissant ainsi une transmission plus fiable. source : http://stop-linky46.fr/tech/cpl.htm

Nota : Les compteurs Linky de génération G1 et G3 partagent la même bande de fréquence CENELEC-A ainsi que les mêmes lignes électriques pour la communication CPL. Afin d'assurer la cohabitation sans interférences, les compteurs G3 laissent volontairement inoccupées les 11 porteuses situées entre les canaux 39 et 49, afin de ne pas perturber les transmissions des compteurs G1 présents sur le réseau.

Identifier la génération de son Linky

Un post du forum forum-photovoltaique.fr fournit des éléments utiles pour identifier les caractéristiques techniques d'un compteur Linky à partir de son numéro de série.

source :https://forum-photovoltaique.fr/viewtopic.php?p=452438#p452438

Dans mon cas, le numéro de série 06 17 64 XXXX XX indique que je possède un compteur Linky de marque ITRON (ce qui est également visible directement sur le boîtier), fabriqué en 2017, de type monophasé 60 A, et appartenant à la génération CPL G3.

Diagnostiquer la communication vers le concentrateur

Un appui simultané et prolongé sur les touches “+” et “–” du compteur Linky permet d'accéder au mode “maintenance”. Ce mode affiche des informations avancées, notamment sur l'état de la communication avec le concentrateur :

pour un compteur G3, l'écran indique s'il est “associé” (connecté) ou “non associé” ;
un indice de qualité de liaison, nommé LQI (Link Quality Information), est également affiché, codé en hexadécimal.

De manière intuitive, plus la valeur LQI est élevée, meilleure est la qualité du lien CPL entre le compteur et le concentrateur mais cela je vais m'en assuré plus tard.

Si je n'avais plus aucun doute sur l'origine de la perturbation affectant la communication de mon compteur Linky, un premier diagnostic sans aucune intervention a confirmé la situation : le compteur était “non associé”, donc hors communication avec le concentrateur (voir photo de gauche).

La technicienne ENEDIS en charge du suivi de mon dossier m'a indiqué de couper le disjoncteur abonné, d'attendre au moins deux heures, puis de relancer la procédure de vérification. Avant même l'écoulement de ce délai, mon compteur s'est automatiquement ré-associé au concentrateur avec un LQI de 0x78.

Il s'agit à présent de déterminer précisément quel équipement est à l'origine des perturbations CPL, les onduleurs solaires soient les premiers suspects.

Je prévois de réaliser un test plus complet en mettant l'intégralité de mon système photovoltaïque hors tension durant mes prochaines vacances. L'objectif est de mesurer le LQI maximal atteignable dans des conditions idéales.

Nota : Pour information, si l'écran affiche “Puiss dépassée” ; le message indique que la puissance souscrite maximale a été dépassée provoquant la coupure d'électricité. Il faut d'abord débrancher les appareils électriques à l'origine de la surconsommation. Pour réarmer votre compteur Linky, il suffit d'appuyer sur le bouton “+” pendant 10 secondes.

Dans mon contexte, l'onduleur hybride, au cœur de l'installation, et le micro-onduleur utilisé pour le couplage AC apparaissent comme les principaux suspects.
Ne pouvant mettre hors tension l'onduleur principal facilement, j'ai commencé par couper le micro-onduleur afin d'observer l'évolution du comportement du compteur Linky.

Résultat : le Linky reste associé, mais avec un indice LQI légèrement dégradé, oscillant entre 0x70 et 0x76.

En revanche, une tentative de remise en service du micro-onduleur entraîne rapidement la perte d'association du compteur avec le concentrateur.

Il ne s'agit pas d'incriminer directement le micro-onduleur, car des éléments de son environnement peuvent également être à l'origine des interférences observées :

fonctionnement du smartload DEYE,
longueur et cheminement des canalisations électriques,
paramétrage réseau de l'onduleur DEYE,
...

Ce dernier point — le paramétrage réseau de l'onduleur DEYE — peut sembler anecdotique. Pourtant, mes recherches autour du dysfonctionnement de mon compteur Linky m'ont permis de découvrir un mauvais réglage de l'onduleur, passé jusque-là inaperçu.

Actions correctives

DEYE low noise mode
Le mode « low noise » de l'onduleur DEYE n'est pas clairement documenté. Cependant, les retours des forums indiquent qu'il permet de modifier la fréquence de découpage, la faisant passer de 15 kHz à 20 kHz, soit en dehors de la plage audible par l'oreille humaine. Les harmoniques des signaux électriques étant de rang impair, elles se situeraient alors à des fréquences telles que 60 kHz, 100 kHz, 140 kHz, etc.
- Avec une fréquence de découpage à 15kHz, l'harmonique de rang 3 à 45kHz est très proche de la sous-porteur CPL n°29 (45.3125 kHz). L'harmonique de rang 5 (75kHz) se situe dans la bande réservée pour le CPL G1, sans influence dans mon cas.
- Avec un fonctionnement à 20kHz, l'harmonique de rang 3 à 60kHz, bien que dans la bande réservée pour le CPL G1, est très proche de la sous-porteur CPL n°38 (59.375 kHz) de la bande inférieure du G3. L'harmonique de rang 5 (100kHz) est hors bande CENELEC-A.

Le choix d'un fonctionnement à 20 kHz paraît plus judicieux, même si la différence peut sembler faible. Les quelques essais effectués avec cette fréquence de découpage semblent indiquer une amélioration, sans perte d'association avec le compteur Linky. Toutefois, ces résultats restent à confirmer par des tests plus approfondis.

Filtre Harmonique

La société espagnole EMIKON propose toute une gamme de filtres spécialisés dans le filtrage de la bande CENELEC-A. Le modèle que j'ai retenu, le (HPF 1065-55) , promet une atténuation de -55 dB pour les fréquences comprises entre 35 kHz et 150 kHz, avec une capacité de tenue en courant allant jusqu'à 65 A.
Étant donné qu'il s'agit d'un filtre coupe-bande, l'atténuation annoncée de -55 dB correspond très probablement au maximum atteint à la fréquence de coupure.
À noter la grande réactivité de Dicel , le revendeur français des produits EMIKON, qui m'a envoyé un devis en moins de 24 heures, avec une livraison du produit — en stock au moment de la commande — effectuée en seulement quelques jours.

Bilan

Le passage en mode « low noise », contraignant le système à une fréquence d'échantillonnage fixée à 20 kHz, permet d'optimiser le rapport signal/bruit (meilleur LQI) ce qui améliore la liaison CPL du compteur Linky. Néanmoins, des pertes de synchronisation persistent lors des phases de transmission nocturne, suggérant une sensibilité résiduelle aux perturbations électromagnétiques transitoires sur le réseau.

En cherchant un moyen de détecter ces pertes de connexion, j'ai découvert que cette information était en réalité déjà disponible dans l'entité STGE (registre de statuts) fournie par l'intégration Linky/Téléinformation. Elle n'apparaît toutefois pas directement, mais reste encodée dans les bits 21 et 22 de ce registre.

Je réalise le décodage de cette information via l'add-on Node-RED de Home Assistant, à l'aide de la fonction JavaScript decodeSTGE suivante :

 let input = msg.payload; // Conversion de l'entrée (chaîne hexadécimale) en entier let payload = parseInt(input, 16); // Objet contenant les différents statuts décodés let status = {}; // Bit 0 : contact sec (inversé : 0 → 1, 1 → 0) status["contact_sec"] = (payload & 0b1) === 0 ? 1 : 0; // Bits 21-22 : statut CPL (2 bits) status["statutCPL"] = (payload >> 21) & 0b11; // Bit 23 : synchro CPL (1 bit) status["synchroCPL"] = (payload >> 23) & 0b1; // Bit 8 : production/consommation (1 bit) status["prodConso"] = (payload >> 8) & 0b1; // Bit 9 : sens de l'énergie (1 bit) status["sensEnergy"] = (payload >> 9) & 0b1; // Couleur du jour (bits 24-25 → 2 bits) status["couleurJour"] = (payload >> 24) & 0b11; // Couleur du lendemain (bits 26-27 → 2 bits) status["couleurDemain"] = (payload >> 26) & 0b11; // Préavis pointes mobiles (bits 28-29 → 2 bits) status["preavisPM"] = (payload >> 28) & 0b11; // En cours de pointes mobiles (bits 30-31 → 2 bits) status["enCoursPM"] = (payload >> 30) & 0b11; // Mise à jour des messages msg.payload = payload; msg.status = status; return msg;

Disposer de cette information de décrochage est intéressant, car elle permet de mettre en œuvre une coupure de l'alimentation de l'onduleur DEYE, soit par une action manuelle (via le disjoncteur de protection), soit de manière automatique, ce qui nécessite toutefois l'ajout d'un contacteur supplémentaire.

L'ajout du filtre a permis de résoudre complètement les problèmes de décrochage dans mon installation. J'ai toutefois adapté son câblage, car il doit protéger les remontées parasitaires de l'onduleur sur les fréquences de la bande CENELEC A vers le réseau Enedis, et non l'inverse. Ainsi, mon onduleur DEYE est connecté aux bornes d'entrée L et N du filtre, tandis que le réseau Enedis est raccordé aux bornes de sortie L' et N'.

Une réflexion plus large...

Le Pulsadis est mort, vive le CPL… Plus sérieusement, certains sites critiques envers le compteur Linky se sont révélés être des sources d'informations pertinentes. J'y ai découvert des points de vue bien argumentés, portés par des personnes sensées et techniquement compétentes (L'auteur des articles techniques stop-linky46.fr ). Je reste cependant réservé vis-à-vis des filtres estampillés « anti-Linky », souvent proposés à des tarifs élevés alors que leurs spécifications techniques restent très proches de celles de filtres plus standards, non marketés autour de cette problématique.