Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:domotique:garagebox [2025/02/10 17:22] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ fr:domotique:garagebox [2025/02/18 13:54] (Version actuelle) – [Ajout LD2420] kodein
@@ Ligne 1: / Ligne 1: @@
+====== Pourquoi domotiser son garage ======
+Comme dirait William : //"Et pourquoi pas ?"// LOL
+Le déclencheur de ce projet, c'est le module détecteur de mouvements / détecteur crépusculaire / timer du spot extérieur des garages qui s'est mis à débloquer plein pot. J'ai essayé de refaire le réglage des trois potards, mais il finit toujours par rester constamment allumé.\\
+Plutôt que remplacer tout le spot ou essayer de retrouver un module identique (qui risque de bug pareil sous peu), c'est l'occase de tenter des bricolages cool. D'autant plus avec le challenge des environnements hostiles (pour l'électronique) que sont l'extérieur et l'intérieur d'un box de garage non isolé, non chauffé.
+Puis en profiter aussi pour ajouter des fonctions qui n'y étaient pas et apprendre à tout ça à dialoguer avec le serveur domotique, tant qu'on y est !
+====== Buts à atteindre ======
+Il y a un strict minimum de fonctionnalités à obtenir :
+  * détecter la présence humaine à proximité des garages
+  * évaluer la luminosité ambiante
+  * commander le (ou les) éclairage(s) extérieur(s)
+  * remonter les infos à mon serveur Home Assistant
+Et ensuite deux fonctions supplémentaires relativement simples à ajouter :
+  * thermomètre et hygromètre extérieur
+Éventuellement, si vraiment tout se passe ultra relax :
+  * thermomètre intérieur
+  * détection présence intérieure
+  * commande des éclairages intérieurs
+  * commande des portes de garage
+Mais dans ce cas, il sera nécessaire de trouver des solutions techniques pour pouvoir mettre des capteurs et actionneurs dans et hors des box.
+===== Choix technologiques =====
+A l'origine, je penchais pour une option à base de modules tout fait zigbee. **Mais** une grande majorité de ces capteurs sont alimentés par piles et ça me gonfle un peu de les remplacer tous les X temps pour que ça continue à fonctionner. Une solution serait de les modifier pour les alimenter par batterie et panneau photovoltaïque, mais ça complexifie beaucoup le système et pour les éléments à l'extérieur, il faut s'assurer que ça reste étanche.\\
+Donc je me suis penché sur d'autres options et ce qui me semble le plus simple serait une solution à base de [[https://esphome.io/|ESPHome]].\\
+Ça tourne sur pcb de dev ESP32/ESP8266 (voir RP2040 mais avec de grosses contraintes niveau modèle) auquel on connecte des modules capteurs et actionneurs "prêts à l’emploi". Et un très large panel de périphériques compatibles est disponible.\\
+La communication avec le serveur se fait en wifi (faudra check si le wifi de la maison arrive jusque là).\\
+Mais le système permet de faire des automatismes en local, ce qui le rend auto-suffisant. Dans mon cas, Home Assistant ne serait là que pour collecter des données, changer des paramètres, modifier les automatismes stockés en local dans l'ESP ou servir de télécommande. (genre pour forcer la lampe allumée sans devoir rajouter de bouton physique dans le garage)
+Une autre option serait d'abandonner ESPHome, de continuer avec des ESP32, mais de la gamme C6 (haute performances) et H2 (très basse consommation électrique) qui sont compatibles Zigbee. Ça demande un peu plus de travail, mais ça a l'avantage de s'intégrer au réseau mesh zigbee déjà existant de la maison. Et si c'est bien fait, de se comporter comme des modules "classiques", donc être intégrable avec n'importe quel central domotique zigbee.\\
+De plus ces deux modèles sont aussi compatibles Matter. Si jamais je migre vers ce système, il serait toujours possible de reflasher un nouveau firmware pour exploiter ce nouveau système.
+===== Choix matériel électronique =====
+Je me suis basé sur le listing du site ESPHome et effectué mon choix d'après les fonctionnalités décrites et la disponibilité à bas coût de modules sur les internets.
+=== Core ===
+<gallery left&nocrop&200x200&lightbox>:domotique:esphome:esp32.png Photo d'un devboard d'ESP32</gallery>Une carte de développement ESP32 Wifi/BLE (normalement, il y a moyen de toutes les exploiter avec ESPHome).
+C'est le système central de la mini installation, les capteurs et actionneurs s'y connectent via les différents bus. Que ça soit SPI, UART, I²C ou simplement GPIO.
+Ces cartes semblent souvent capables de supporter un large panel de tensions en alimentation. Je pense donc l'alimenter via un transfo 230V AC - 12V DC.
+Certains modèles possèdent un connecteur ipex permettant d'utiliser une antenne plus imposante que celle intégrée au pcb et surtout permettant de la déporter pour améliorer la réception du signal. Ce genre de modèle me semble plus adapté pour mon usage.
+=== Capteur lumière et UV ===
+<gallery left&nocrop&200x200&lightbox>:domotique:esphome:ltr390.png Photo d'un module LTR390</gallery>Un capteur LTR390 pour mesurer la luminosité ambiante, ce capteur permet aussi de mesurer le rayonnement UV.
+C'est grace à lui que le core va pouvoir vérifier si la luminosité ambiante justifie l'allumage du spot extérieur.
+Connecté sur le BUS I²C.
+=== Capteur de présence ===
+<gallery left&nocrop&200x200&lightbox>:domotique:esphome:ld2420.png Photo d'un module LD2420 avec ses antennes intégrées au PCB</gallery>Le LD2420 permet non de détecter les mouvements, mais de détecter la présence de trucs qui sont pas là habituellement en utilisant des ondes radios. Il est possible de régler la puissance (donc la distance de détection), la sensibilité ainsi que de calibrer le radar via ESPHome.
+Comme c'est un détecteur de présence, le timer est moins utile : tant que quelqu'un est détecté dans la zone, la lampe peut rester allumée. Je vais quand même mettre un délais à l'extinction, histoire de ne pas faire guirlande de noël quand on bosse à la bordure de la zone de détection.
+Connecté en UART et/ou GPIO qui remonte uniquement si une présence est détectée ou non (mais ne permet pas de toucher aux paramètres, ni la remontée d'infos supplémentaires).
+=== Capteur température, pression et humidité ===
+<gallery left&nocrop&200x200&lightbox>:domotique:esphome:bme280.png Photo d'un breakout board BME280</gallery>Un capteur BME280 permet de collecter des informations météorologiques. Pas du tout essentiel pour le bon fonctionnement de cette installation, mais le module est assez peu cher. Il me semble donc sympathique d'ajouter ces fonctions pour remonter plus d'infos au serveur Home Assistant.
+Connecté en I²C.
+=== Actionneur lumière ===
+<gallery left&nocrop&200x200&lightbox>:domotique:esphome:relay3_3-230.png Photo d'un module relais</gallery>Au moins un relais dont la commande puisse se faire en 3.3v et dont les contacts permettent de piloter du 230V. Bien des modules de ce genre sont disponibles sur les différentes plateformes de vente. La plupart sont isolés par des optocoupleurs, ce qui permet de protéger le MCU de tout mauvais fonctionnement de la partie basse tension (230V).
+Connecté sur un GPIO.
+====== Essais ======
+J'ai acheté "un peu" de matériel pour réaliser plusieurs montages en parallèle et pouvoir les tester sans devoir démonter un pour faire l'autre.
+  * 5 ESP32 "classiques" avec connecteur antenne ipex
+  * 1 ESP32-C6 (zigbee)
+  * 1 ESP32-H2 (zigbee)
+  * 2 LD2420 (radar)
+  * 1 LTR390 (lumière)
+  * 2 BME280 (t°)
+  * 5 relais avec optocoupleurs
+  * 2 kits solaires avec un porte li-ion 18650
+  * 1 DC-DC converter qui accepte 1 à 6V en entrée et sort 3.3V (j'aurais du en prendre 3, mais…)
+Ça devrait me permettre de réaliser quelques essais sans trop me prendre le choux.
+===== Test001 ESPHome =====
+Autant débuter par un truc simple sans faire non plus dans le simpliste (j'ai pas envie de juste lire/écrire des GPIO), donc récupérer les données d'un capteur de t° et les remonter au central domotique.
+Si j'arrive déjà à faire ça, ça veut dire que le esp32 parle via I²C au capteur et transmet les valeurs via wifi au serveur domotique.
+Le tout sera alimenté directement par un chargeur USB, histoire de pas trop se casser les bonbons.
+==== Firmware ====
+Le plus complexe pour moi, c'est faire le programme. N'ayant jamais utilisé ESPHome, faut le temps d'apprendre quoi mettre dans le code pour obtenir le fonctionnement désiré et comment pousser ce code dans l'ESP32.
+=== Initialiser le core ===
+Dans un premier temps, je suis passé par l'interface graphique du plugin ESPHome Device Builder de Home Assistant et un pc avec chromium.
+Ce qui a permis d'assez facilement pousser un premier programme plus ou moins vide dans un ESP32-WROOM-32U surnommé "test001".
+Mais dès que le code s'est étoffé, le raspi s'est retrouvé à bout de souffle pendant la compilation.
+Pour soulager ce pauvre raspi il a fallu installer les outils CLI ESPHome sur un "vrai" ordi. Ça prends tout de suite vraiment beaucoup moins de temps pour compiler et je peux pousser le firmware directement par usb dans le core sans passer par un navigateur web.
+=== Voyons ce code ===
+<code yaml>esphome:
+  name: test001
+  friendly_name: test001
+esp32:
+  board: esp32dev
+  framework:
+    type: arduino
+# Enable logging
+logger:
+# Enable Home Assistant API
+api:
+  encryption:
+    key: !secret ota_key
+ota:
+  - platform: esphome
+    password: !secret ota_password
+wifi:
+  ssid: !secret wifi_ssid
+  password: !secret wifi_password
+  # Enable fallback hotspot (captive portal) in case wifi connection fails
+  ap:
+    ssid: "Test001 Fallback Hotspot"
+    password: !secret fallback_wifi_password
+captive_portal:
+time:
+  - platform: homeassistant
+    id: homeassistant_time</code>
+Ici on a tout le setup de base du module ESPHome, j'y ai ajouté une sync avec l'horloge du serveur. Ça coute rien et ça peut m'éviter des surprises si je prévois des automatismes interne à l'esp basés sur l'heure.
+<code yaml>i2c:
+  sda: GPIO21
+  scl: GPIO22
+  scan: true
+  id: bus_a
+</code>
+On initialise le bus I²C sur les pins 21 pour SDL et 22 pour SDA et on le désigne par l'identifiant bus_a. Rien de bien folichon.
+<code yaml>
+sensor:
+  - platform: bme280_i2c
+    address: 0x76
+    temperature:
+      name: "BME280 Temperature"
+    pressure:
+      name: "BME280 Pressure"
+    humidity:
+      name: "BME280 Humidity"</code>
+On définit d'abord le type de capteur, ici un BME280.\\
+Ensuite, petite subtilité, mon capteur n'était pas détecté par l'ESP. J'ai poussé un sketch sniffeur d'adresse I²C sur un arduino. Il m'a signalé qu'un truc répondait à l'adresse 0x76 après avoir câblé le capteur dessus. Évidemment, l'adresse par défaut pour ces capteurs dans ESPHome est 0x77, ça ne risquait pas de fonctionner. Après avoir spécifié l'adresse, on obtient bien les remontées de valeurs du capteurs.\\
+Puis les différentes valeurs à remonter au serveur et le nom sous lequel les afficher. J'ai laissé les noms par défauts donnés sur le site ESPHome parce que c'est avant tout un proto, il n'est pas destiné à être utilisé tel quel.
+==== Hardware ====
+C'est très simple de câbler un capteur I²C sur le core, seuls 4 fils suffisent :
+  * GND sur GND
+  * 3.3V sur 3.3V
+  * SDA sur gpio 21
+  * SCL sur gpio 22
+<gallery center&nocrop&400x400&lightbox>:domotique:esphome:test001_wiring_001.png Simulation de câblage | Illustration du câblage d'un BME280 à un ESP32</gallery>
+==== Résultats ====
+Dans un premier temps je n'avais que ça :
+<gallery center&nocrop&400x400&lightbox>:domotique:esphome:prinscreen_test001_0001.png Infos du module test001 dans Home Assistant | Le module est bien visible, mais ne remonte pas de données de t° etc.</gallery>
+Après avoir corrigé l'adresse dans le code :
+<gallery center&nocrop&400x400&lightbox>:domotique:esphome:prinscreen_test001_0002.png Infos du module test001 dans Home Assistant après correction | Le module est présent et remonte des données de t° etc.</gallery>
+C'est officiellement un grand succès!
+==== Ajout LTR390 ====
+Ajouter le capteur lumière et UV est vraiment trivial. Le bus I²C est déjà initialisé, il y a juste à brancher les quatre pins du capteurs sur les mêmes pins du core que le BME280. Et niveau code, c'est pas plus compliqué que pour le BME on rajoute ça dans la section "sensor" :
+<code yaml>  - platform: ltr390
+    uv_index:
+      name: "UV Index"
+    uv:
+      name: "UV Sensor Counts"
+    light:
+      name: "Light"
+    ambient_light:
+      name: "Light Sensor Counts"
+</code>
+<gallery center&nocrop&400x400&lightbox>:domotique:esphome:test001_wiring_002.png Simulation de câblage | Illustration du câblage d'un BME280 et LTR390 à un ESP32</gallery>
+Et ça fonctionne directement.
+<gallery center&nocrop&400x400&lightbox>:domotique:esphome:photo001.jpg Photo du prototype câblé et fonctionnel | Le câblage laisse à désirer : les fils aux couleurs fantaisistes, de longueurs mal adaptée et l'esp à cheval sur 2 breadboard >.> </gallery>
+==== Ajout LD2420 ====
+Le radar à ondes millimétriques est assez simple à raccorder physiquement, encore une fois 4 fils suffisent :
+  * 3.3V sur 3.3V
+  * GND sur GND
+  * RX sur TX0 coté ESP
+  * OT1 sur RX0 coté ESP (mais en fonction de la version du firmware du LD2420, ça peut aussi être OT2)
+Si on rajoute un cinquième fil, on peut avoir le retour sur GPIO de la présence détectée ou non et éventuellement pouvoir utiliser des modes plus économes en énergie sur l'ESP avec le GPIO qui vient le réveiller. Dans mon cas, pas très utile, le montage ne tournant pas sur batterie et la consommation étant déjà très faible.
+Il faut d'abord configurer le bus UART qu'on va exploiter pour le capteur. Comme on a déjà un UART défini pour le logging, il va être nécessaire de leurs attribuer des ID histoire de bien séparer les flux.
+<code yaml>
+logger:
+  id: logz
+[…]
+uart:
+  tx_pin: GPIO17
+  rx_pin: GPIO16
+  baud_rate: 115200
+  id: radar
+</code>
+Comme ça, on ne risque pas d'aller écrire les messages de logs sur l'uart dédié au capteur et/ou inversement.\\
+La vitesse de l'UART est aussi spécifiée pour assurer la compatibilité avec le LD2420 et pareil, si vous avez le firmware avec le TX sur OT2, il sera nécessaire de passer ce paramètre à 256000.
+Ensuite, le code pour le module n'est pas complexe mais très long parce qu'il comporte de très nombreuses variables pour configurer le capteur. Et à partir de maintenant je ne mettrai plus le code issu directement de copier/coller depuis ESPHome pour limiter les gros pavés de code indigeste. Par contre, je continuerai à montrer le code "made in moi" pour régler les petits problèmes rencontrés (genre l'ajout d'ID des UART xD).
+Et donc, avec cette config, le radar fonctionne étonnamment bien. Il retourne des valeurs un peu "inventives" pour la distance, mais il détecte parfaitement ma présence même en étant face au plafond. J'ai du sortir de la pièce et me mettre assez loin de l'embrasure de la porte pour qu'il ne me capte plus.\\
+J'imagine que dans une zone libre comme devant le garage et avec une calibration et un paramétrage correct, on devrait avoir des lectures plutôt saines des distances.
+==== Automatisation ====
+===== On garde globalement les mêmes, mais en zigbee =====
+Ouais, pour tester et comparer le rapport emmerdement/bénéfices.
+J'aimerais aussi beaucoup pouvoir comparer la couverture réseau entre les deux. Surtout que sous peu, quelques modules zigbee supplémentaires devraient être installés dans la maison.

Outils pour utilisateurs

Outils du site

Différences

Outils de la page