🌡️ Système de climatisation naturelle intelligente

🎯 Objectif

L'objectif du projet est de créer une application permettant de surveiller la température et l'humidité à l'intérieur et à l'extérieur d'une habitation afin de déterminer automatiquement les meilleurs moments pour ventiler naturellement la maison.

Le système doit permettre de :

L'objectif final est de réaliser une forme de climatisation naturelle intelligente.

🏠 Principe général

Le principe est extrêmement simple :

MESURER → COMPARER → ANALYSER → DÉCIDER → AGIR

Les principales informations utilisées sont :

Le système compare en permanence les conditions intérieures et extérieures.

☀️ Fonctionnement en été

Pendant une période chaude, la maison peut être plus chaude que l'extérieur.

Exemple :

La différence est de 5 °C.

Dans cette situation, il est intéressant de faire entrer l'air extérieur.

Le système peut alors proposer :

🟢 OUVRIR LES FENÊTRES

et éventuellement :

🟢 ALLUMER LES VENTILATEURS

L'objectif est de remplacer progressivement l'air chaud intérieur par de l'air extérieur plus frais.

🌙 Rafraîchissement nocturne

Le rafraîchissement nocturne est probablement l'utilisation la plus intéressante du système.

Pendant la journée, la maison peut accumuler beaucoup de chaleur.

Exemple :

22:00

Il n'est pas encore intéressant d'ouvrir largement.

Puis pendant la nuit :

01:00

Le système détecte alors une différence importante.

Il peut recommander :

🟢 OUVRIR LES FENÊTRES

🟢 OUVRIR LES PORTES INTÉRIEURES

🟢 ALLUMER LES VENTILATEURS

Quelques heures plus tard :

04:00

Le système peut décider d'arrêter les ventilateurs et éventuellement de fermer les ouvertures afin d'éviter de trop refroidir la maison.

❄️ Fonctionnement en hiver

Le principe peut également fonctionner dans l'autre sens.

Si l'extérieur est plus chaud que l'intérieur, on peut profiter de cette chaleur.

Exemple :

Le système peut alors considérer qu'une ventilation naturelle est intéressante.

Il peut proposer :

🟢 OUVRIR LES FENÊTRES

afin de faire entrer de l'air plus chaud.

Les règles d'hiver devront cependant être différentes des règles d'été.

💧 Importance de l'humidité

La température seule ne suffit pas.

Il faut également mesurer l'humidité.

Exemple :

Même si l'extérieur est plus frais, ouvrir les fenêtres peut faire entrer beaucoup d'humidité.

Le système devra donc pouvoir tenir compte simultanément :

température + humidité

Cela permettra de prendre de meilleures décisions.

🧠 Moteur de décision

Le cœur de l'application sera un moteur de décision.

Il pourra par exemple déterminer trois états principaux :

🟢 REFROIDIR

🟠 CHAUFFER

⚪ NE RIEN FAIRE

Exemple de règle estivale :

Si la température intérieure est supérieure à 26 °C et que la température extérieure est inférieure d'au moins 1 °C à la température intérieure, alors le refroidissement naturel est possible.

Exemple :

Résultat :

🟢 REFROIDISSEMENT POSSIBLE

🔄 Hystérésis

Il faudra utiliser une hystérésis pour éviter que les équipements ne changent continuellement d'état lorsque les températures sont très proches.

Par exemple :

Ventilateur ON :

écart intérieur/extérieur ≥ 1,5 °C

Ventilateur OFF :

écart intérieur/extérieur ≤ 0,5 °C

Ainsi, on évite une succession de commandes :

ON → OFF → ON → OFF → ON → OFF

lorsque les températures sont presque identiques.

🌡️ Choix des capteurs

Une première possibilité était de fabriquer des capteurs avec :

Cette solution est parfaitement réalisable.

Cependant, elle nécessite de programmer les ESP32 et de gérer :

Une solution commerciale Zigbee est donc beaucoup plus simple pour commencer.

📡 SONOFF SNZB-02DR2

Le capteur envisagé est le :

SONOFF AirGuard TH SNZB-02DR2

C'est un capteur Zigbee de température et d'humidité avec écran LCD.

Il présente plusieurs caractéristiques intéressantes :

Le prix observé est d'environ 12 € pour un capteur, ce qui rend possible l'installation de plusieurs points de mesure à faible coût.

📡 Pourquoi Zigbee ?

Le Wi-Fi n'est pas forcément idéal pour des capteurs fonctionnant sur batterie.

Zigbee est conçu pour des appareils basse consommation.

Le capteur peut donc rester très longtemps sur batterie tout en transmettant périodiquement ses mesures.

L'architecture est :

SNZB-02DR2 → Zigbee → coordinateur Zigbee → Zigbee2MQTT → MQTT → application

L'avantage important est que le capteur n'a pas besoin d'être programmé.

🔌 Zigbee2MQTT

Zigbee2MQTT permet de récupérer les informations provenant des appareils Zigbee et de les publier via MQTT.

Pour le SNZB-02DR2, les informations importantes sont notamment :

L'architecture devient :

SNZB-02DR2 intérieur
↓
Zigbee
↓
Coordinateur Zigbee
↓
Zigbee2MQTT
↓
MQTT
↓
PHP
↓
SQLite
↓
HTML + JavaScript

Le même principe est utilisé pour le capteur extérieur.

🏠🌳 Deux capteurs

La première installation peut utiliser simplement deux capteurs.

Capteur 1 : intérieur

SNZB-02DR2 installé dans une pièce représentative de la maison.

Capteur 2 : extérieur

SNZB-02DR2 installé à l'extérieur, dans un emplacement approprié et protégé des conditions pouvant fausser la mesure, notamment le rayonnement solaire direct.

Les deux capteurs fournissent :

L'application peut alors comparer les deux mesures.

🖥️ Architecture logicielle

L'architecture générale envisagée est :

CAPTEUR INTÉRIEUR
↓
Zigbee

CAPTEUR EXTÉRIEUR
↓
Zigbee

Les deux flux arrivent au :

Coordinateur Zigbee

puis :

Zigbee2MQTT

puis :

MQTT

puis :

PHP

PHP peut enregistrer les données dans :

SQLite

JavaScript peut ensuite récupérer les données et les afficher dans :

HTML + JavaScript

💾 Base SQLite

SQLite peut conserver toutes les mesures.

Une table pourrait contenir :

Exemple conceptuel :

Date Capteur Température Humidité
01:00 intérieur 27,2 °C 55 %
01:00 extérieur 21,3 °C 72 %
01:05 intérieur 27,0 °C 55 %
01:05 extérieur 21,1 °C 73 %

Ces données permettront de conserver l'historique complet du comportement thermique de la maison.

📈 Graphiques

L'application pourra afficher :

Les périodes pourront être :

Un graphique permettra notamment de visualiser les périodes pendant lesquelles le refroidissement naturel est efficace.

🌀 Commande des ventilateurs

Une fois la partie mesure parfaitement fonctionnelle, les ventilateurs pourront être automatisés.

Exemple de logique :

Si :

alors :

ventilateur = ON

Le ventilateur pourra être arrêté lorsque :

température extérieure ≥ température intérieure - 0,5 °C

ou lorsque les autres conditions nécessaires ne sont plus remplies.

🪟 Commande des fenêtres

La même logique pourra être utilisée pour des fenêtres motorisées.

Exemple :

Décision :

🟢 OUVRIR

Puis :

Décision :

🔴 FERMER

La commande des fenêtres nécessite toutefois beaucoup plus de sécurité que la commande d'un ventilateur.

Il faudra notamment tenir compte de :

🌧️ Évolutions possibles

Le système pourra ensuite intégrer d'autres informations :

Le système pourrait alors éviter d'ouvrir les fenêtres lorsqu'un épisode pluvieux est prévu ou lorsque le vent est trop important.

☀️ Gestion du soleil

Une évolution intéressante serait également de tenir compte de l'ensoleillement.

Une maison exposée au soleil peut continuer à chauffer même lorsque la température extérieure commence à baisser.

Le système pourrait donc utiliser :

Cela permettrait de déterminer plus précisément le moment où il devient intéressant de commencer la ventilation nocturne.

🤖 Automatisation progressive

Le développement doit être réalisé progressivement.

Étape 1 — Mesure

Installer deux capteurs :

Vérifier que les données sont correctement récupérées.

Étape 2 — MQTT

Installer et configurer :

Vérifier que les deux capteurs transmettent correctement leurs données.

Étape 3 — PHP

Créer un programme PHP capable de récupérer les données MQTT ou de les recevoir via un mécanisme intermédiaire.

PHP doit pouvoir obtenir :

Étape 4 — SQLite

Enregistrer périodiquement les mesures.

Étape 5 — Interface Web

Créer une page HTML + JavaScript affichant :

Étape 6 — Graphiques

Ajouter l'historique.

Étape 7 — Moteur de décision

Ajouter les règles de :

Étape 8 — Ventilateurs

Ajouter la commande automatique des ventilateurs.

Étape 9 — Fenêtres

Ajouter éventuellement les ouvertures motorisées.

🎯 Première version de l'application

La première version ne doit surtout pas commander directement les équipements.

Elle doit uniquement :

  1. récupérer les données ;
  2. les enregistrer ;
  3. les afficher ;
  4. comparer les températures ;
  5. calculer les écarts ;
  6. proposer une décision.

L'interface pourrait afficher :

🏠 Température intérieure : 27,8 °C

🌳 Température extérieure : 22,4 °C

💧 Humidité intérieure : 52 %

💧 Humidité extérieure : 48 %

🌡️ Écart : -5,4 °C

🟢 REFROIDISSEMENT POSSIBLE

🟢 OUVRIR LES FENÊTRES

🟢 VENTILATEURS

Cette première étape permettra de vérifier que les décisions sont pertinentes avant d'autoriser une automatisation réelle.

🏗️ Architecture finale

L'architecture complète pourrait finalement être :

MAISON
↓
Capteur intérieur + capteur extérieur
↓
Zigbee
↓
Coordinateur Zigbee
↓
Zigbee2MQTT
↓
MQTT
↓
PHP
↓
SQLite
↓
Moteur de décision
↓
Commandes
↓
Ventilateurs / fenêtres / volets
↓
HTML + JavaScript
↓
Interface Web

🧠 Principe fondamental

Le système doit toujours fonctionner selon le principe :

MESURER

↓

COMPARER

↓

ANALYSER

↓

DÉCIDER

↓

AGIR

↓

MESURER À NOUVEAU

Il s'agit donc d'une boucle de régulation.

L'application ne doit pas simplement afficher des températures : elle doit progressivement apprendre à déterminer quand il est avantageux de laisser entrer ou sortir de la chaleur.

🌡️ Exemple complet en été

Situation à 22:00 :

Décision :

⚪ Attendre

Situation à 01:00 :

Décision :

🟢 Ouvrir

🟢 Ventiler

Situation à 03:00 :

Décision :

🟡 Réduire ou arrêter les ventilateurs

Situation à 05:00 :

Décision :

🔴 Fermer les ouvertures

La maison est ainsi refroidie naturellement avant le lever du soleil.

🎯 Objectif final

Le projet doit aboutir à une véritable gestion intelligente du climat de l'habitation, sans nécessairement utiliser une climatisation classique.

Le système pourra :

La philosophie du projet est donc :

utiliser en priorité les conditions naturelles disponibles pour maintenir une température intérieure confortable.

🚀 Architecture de départ recommandée

Pour commencer, la configuration la plus simple est :

2 × SONOFF SNZB-02DR2

→ un capteur intérieur
→ un capteur extérieur

puis :

Coordinateur Zigbee

→ Zigbee2MQTT

→ MQTT

→ PHP

→ SQLite

→ HTML + JavaScript

Cette architecture évite de programmer un ESP32 et permet de commencer directement par la partie réellement intéressante du projet : la comparaison des températures et la création du moteur de décision.

Les automatismes physiques seront ajoutés seulement après validation du fonctionnement de cette première partie.

🌡️ Architecture du système de climatisation naturelle

🎯 Objectif

L'objectif est de créer un système permettant de mesurer la température intérieure et extérieure d'une habitation et d'utiliser ces informations pour déterminer les meilleurs moments pour :

Le système doit surtout fonctionner sans ordinateur dédié allumé 24 h/24.

La tablette ou le smartphone doivent pouvoir être utilisés uniquement lorsque l'on souhaite consulter ou piloter le système.

❌ Ce que l'on ne veut pas

On ne veut pas avoir une architecture de ce type :

Ordinateur dédié
↓
Zigbee2MQTT
↓
MQTT
↓
PHP
↓
SQLite

avec l'ordinateur obligé de fonctionner en permanence.

Cette solution fonctionnerait, mais elle est inutilement lourde pour le besoin.

Il n'est pas nécessaire de faire fonctionner un serveur informatique complet 24 heures sur 24 uniquement pour mesurer deux températures.

✅ Architecture recherchée

L'architecture souhaitée est beaucoup plus simple :

🌡️ Capteur intérieur
↓
🌡️ Capteur extérieur
↓
📡 Hub Zigbee / Wi-Fi
↓
📱 Tablette ou smartphone

Le hub Zigbee doit être capable de fonctionner de manière autonome.

La tablette se connecte au hub lorsque l'utilisateur le souhaite.

📡 Principe général

Les capteurs SONOFF fonctionnent sur batterie et communiquent en Zigbee.

Le hub reçoit les informations.

Le hub peut ensuite communiquer avec la tablette par le réseau Wi-Fi.

L'architecture devient donc :

🌡️ SONOFF intérieur
│
🌡️ SONOFF extérieur
│
│ Zigbee
▼
📡 Coordinateur / Hub Zigbee
│
│ Wi-Fi
▼
📱 Tablette Android

La tablette peut alors récupérer les informations du hub.

📱 Rôle de la tablette

La tablette devient l'interface utilisateur du système.

Elle peut exécuter l'application lorsque l'utilisateur en a besoin.

L'application peut être développée avec :

Elle peut afficher :

🧠 Le moteur de décision

L'application peut analyser les températures lorsqu'elle est utilisée.

Par exemple :

Température intérieure : 28 °C

Température extérieure : 22 °C

Écart : -6 °C

L'application peut afficher :

🟢 REFROIDISSEMENT POSSIBLE

🟢 OUVRIR LES FENÊTRES

🟢 ALLUMER LES VENTILATEURS

À l'inverse :

Température intérieure : 25 °C

Température extérieure : 32 °C

L'application peut afficher :

🔴 NE PAS OUVRIR

🔴 CONSERVER LES FENÊTRES FERMÉES

💾 Conservation des données

Il existe deux possibilités.

Solution A — La tablette fait tout

Architecture :

🌡️ Capteurs
↓
Zigbee
↓
📡 Hub
↓
Wi-Fi
↓
📱 Tablette
↓
PHP + SQLite + JavaScript

Dans cette solution, la tablette récupère les données lorsqu'elle est allumée.

Elle peut ensuite :

Cette solution est très simple.

🗄️ Solution B — Le hub conserve les données

Architecture :

🌡️ Capteurs
↓
Zigbee
↓
📡 Hub Zigbee
↓
stockage local
↓
Wi-Fi
↓
📱 Tablette

Dans cette architecture, le hub continue à fonctionner même lorsque la tablette est éteinte.

Il peut conserver les mesures.

Lorsque la tablette est allumée, l'application récupère les données du hub.

Cette solution est probablement encore plus intéressante.

⭐ Solution privilégiée

Pour ce projet, la solution B est à privilégier.

Le système permanent serait extrêmement réduit :

Il n'y aurait pas besoin d'un PC ou d'un serveur informatique fonctionnant 24 h/24.

La tablette pourrait rester éteinte pendant plusieurs heures ou plusieurs jours.

Le système de mesure continuerait à fonctionner.

Lorsque l'utilisateur allume la tablette, l'application peut récupérer les données.

🔋 Avantage énergétique

Cette architecture est également intéressante du point de vue de la consommation électrique.

Les capteurs Zigbee fonctionnent sur batterie.

Le hub consomme beaucoup moins qu'un ordinateur complet.

La tablette n'a pas besoin de rester allumée.

On évite donc :

Le système permanent peut rester très simple.

🌐 Communication locale

L'idéal serait que la communication soit entièrement locale.

Le système pourrait fonctionner ainsi :

Capteurs
↓
Zigbee
↓
Hub
↓
Wi-Fi local
↓
Tablette

Il ne serait donc pas nécessaire de dépendre d'un service cloud pour consulter les températures.

Cela présente plusieurs avantages :

🔌 API locale

Un point particulièrement intéressant serait que le hub dispose d'une API locale.

L'application de la tablette pourrait alors demander au hub :

« Donne-moi la température intérieure. »

Puis :

« Donne-moi la température extérieure. »

Puis :

« Donne-moi l'historique. »

L'application pourrait ensuite effectuer ses propres calculs.

Par exemple :

Température intérieure = 27,8 °C

Température extérieure = 21,4 °C

Différence = -6,4 °C

L'application peut alors déterminer :

🟢 Conditions très favorables au refroidissement naturel.

🏠 Exemple de fonctionnement nocturne

Pendant la journée :

Intérieur : 30 °C

Extérieur : 32 °C

Décision :

🔴 NE PAS OUVRIR

La maison reste fermée.

Pendant la nuit :

Intérieur : 28 °C

Extérieur : 21 °C

Décision :

🟢 OUVRIR

Les fenêtres peuvent être ouvertes.

Les ventilateurs peuvent éventuellement être activés.

Quelques heures plus tard :

Intérieur : 22 °C

Extérieur : 18 °C

Décision :

🟡 ARRÊTER LA VENTILATION

Puis éventuellement :

🔴 FERMER LES OUVERTURES

La maison conserve alors le bénéfice du refroidissement nocturne.

🌀 Évolution vers l'automatisation

Dans un premier temps, l'application ne commande rien.

Elle donne simplement une recommandation.

Exemple :

🟢 OUVRIR LES FENÊTRES

Puis, lorsque le fonctionnement est parfaitement validé, on peut ajouter la commande automatique des ventilateurs.

Enfin, dans une étape ultérieure, on peut ajouter :

Cette progression permet de limiter les risques.

🤖 Fonctionnement avec tablette éteinte

Il faut distinguer deux fonctions.

Surveillance

Les capteurs et le hub peuvent continuer à mesurer les températures lorsque la tablette est éteinte.

Décision

Si l'on veut que le système prenne automatiquement des décisions lorsque la tablette est éteinte, le hub doit disposer lui-même d'un moteur d'automatisation.

Dans ce cas :

Capteurs
↓
Hub
↓
Moteur d'automatisation
↓
Ventilateurs / fenêtres

La tablette devient alors simplement l'interface de contrôle.

Elle permet de consulter et de modifier les paramètres sans être nécessaire au fonctionnement permanent.

📱 La tablette devient donc une console

La tablette n'est plus un serveur permanent.

Elle devient une console de supervision et de commande.

Elle peut afficher une page comme :

🌡️ CLIMATISATION NATURELLE

🏠 Intérieur : 27,8 °C

🌳 Extérieur : 21,4 °C

💧 Humidité intérieure : 52 %

💧 Humidité extérieure : 68 %

🌡️ Écart : -6,4 °C

🟢 REFROIDISSEMENT POSSIBLE

🟢 OUVRIR LES FENÊTRES

🟢 VENTILATEURS

L'utilisateur peut alors décider d'appliquer ou non la recommandation.

🏗️ Architecture idéale du projet

L'architecture recherchée devient donc :

CAPTEURS

🌡️ SONOFF intérieur
🌡️ SONOFF extérieur

↓

ZIGBEE

↓

HUB ZIGBEE / WI-FI

↓

RÉSEAU LOCAL

↓

TABLETTE ANDROID

↓

APPLICATION PHP + HTML + JAVASCRIPT

Le hub peut éventuellement assurer :

La tablette assure :

🎯 Architecture finale recherchée

Le système idéal serait donc :

🌡️ Capteurs Zigbee

→ basse consommation
→ fonctionnement sur batterie

↓

📡 Hub Zigbee/Wi-Fi

→ autonome
→ pas de PC nécessaire
→ éventuellement stockage local
→ éventuellement automatisation

↓

📱 Tablette

→ application Web
→ PHP
→ HTML
→ JavaScript
→ affichage des données
→ graphiques
→ configuration
→ commande

🚀 Avantage principal

Cette architecture répond exactement au besoin initial :

ne pas avoir un ordinateur qui travaille 24 heures sur 24.

Les capteurs peuvent fonctionner en permanence.

Le petit hub peut fonctionner en permanence.

La tablette, elle, peut être :

Le système devient donc beaucoup plus léger, plus économique et plus cohérent avec une installation domestique.

🔎 Point important pour la prochaine étape

Il faut maintenant rechercher précisément un hub Zigbee autonome avec Wi-Fi, capable de :

  1. recevoir les capteurs SONOFF SNZB-02DR2 ;
  2. fonctionner sans ordinateur ;
  3. communiquer localement en Wi-Fi ;
  4. conserver éventuellement un historique ;
  5. disposer d'une API locale ;
  6. permettre à une application PHP/JavaScript de récupérer les données ;
  7. fonctionner sans cloud obligatoire.

C'est ce type de dispositif qu'il faut rechercher avant de choisir définitivement le matériel.

Projet de mesure des températures intérieure et extérieure

Objectif

Mettre en place un système permettant de mesurer :

Principe retenu

Le projet doit privilégier une solution :

Tasmota

Tasmota est le choix privilégié pour la partie électronique.

Il permet notamment :

Architecture envisagée

        CAPTEUR INTÉRIEUR
              │
              │
              ▼
        ┌─────────────┐
        │   Tasmota   │
        │    ESP32    │
        └──────┬──────┘
               │
               │ MQTT / Wi-Fi
               ▼
        ┌─────────────┐
        │   Serveur   │
        │    local    │
        └──────┬──────┘
               │
               ▼
       Affichage / PHP /
       historique / graphiques


        CAPTEUR EXTÉRIEUR
              │
              │
              ▼
        ┌─────────────┐
        │   Tasmota   │
        │    ESP32    │
        └──────┬──────┘
               │
               │ MQTT / Wi-Fi
               ▼
        ┌─────────────┐
        │   Serveur   │
        │    local    │
        └─────────────┘




# Solution retenue — Mesure des températures intérieure et extérieure

## Objectif

Mettre en place un système permettant de mesurer :

- la température intérieure ;
- la température extérieure ;

avec une solution autonome, locale et fiable.

Le système ne doit pas nécessiter qu'un ordinateur fonctionne 24 heures sur 24.

## Solution retenue

La solution retenue repose sur **Tasmota** et des appareils Wi-Fi autonomes compatibles avec Tasmota.

Chaque appareil de mesure communique directement avec le réseau Wi-Fi local.

## Principe

Le système sera composé de deux points de mesure :

- un capteur de température placé à l'intérieur ;
- un capteur de température placé à l'extérieur.

Les mesures pourront ensuite être récupérées sur le réseau local et exploitées par le système de supervision choisi.

## Pourquoi Tasmota

Tasmota est particulièrement adapté au projet parce qu'il permet :

- un fonctionnement local ;
- l'absence de dépendance à un cloud propriétaire ;
- une interface Web intégrée ;
- une communication MQTT ;
- une interrogation des appareils directement sur le réseau ;
- des automatisations locales ;
- une grande souplesse de configuration.

Cela correspond bien à l'objectif recherché : garder la maîtrise du système et éviter une dépendance à une plateforme propriétaire.

## Architecture

Le principe général est :

Capteur intérieur → Wi-Fi → réseau local

Capteur extérieur → Wi-Fi → réseau local

Les deux appareils sont autonomes et n'ont pas besoin d'un ordinateur dédié pour fonctionner.

## Ordinateur 24 h/24

Il n'est pas nécessaire d'utiliser un ordinateur permanent uniquement pour faire fonctionner les capteurs.

Les appareils Tasmota assurent eux-mêmes leur fonctionnement et leur communication.

Un ordinateur ou un autre système de supervision pourra éventuellement être utilisé plus tard pour enregistrer et afficher l'historique des températures, mais il ne constitue pas le cœur du fonctionnement des capteurs.

## Technologie écartée

Les solutions basées sur Tuya ne font pas partie de l'architecture retenue.

L'objectif est de privilégier une solution ouverte, locale et maîtrisable.

## Point important

Il ne faut pas utiliser de dongle USB Zigbee comme élément central du système.

Un dongle USB nécessiterait normalement un équipement informatique fonctionnant en permanence pour assurer le rôle de coordinateur Zigbee.

Ce n'est donc pas la solution recherchée.

## Conclusion

La solution cohérente retenue est :

**Tasmota + capteurs Wi-Fi autonomes + réseau local.**

Le projet doit maintenant se concentrer uniquement sur le choix concret de deux appareils compatibles avec cette architecture :

1. un appareil pour mesurer la température intérieure ;
2. un appareil adapté à la mesure de la température extérieure.

L'objectif est de disposer d'une installation simple, autonome, locale et durable, sans Tuya et sans ordinateur fonctionnant 24 h/24.

Guide : Architecture Domotique Autonome pour Capteurs Zigbee

Objectif

Récupérer les données de température de capteurs Zigbee (type Sonoff SNZB-02) via des scripts personnalisés (PHP/JavaScript), sans abonnement cloud, sans infrastructure serveur permanente (type Raspberry Pi 24h/24) et en maîtrisant totalement le matériel.

La Solution Technique : Passerelle Zigbee "Over-the-Air" (OTA) sous Tasmota

La stratégie la plus intelligente consiste à détourner une passerelle Zigbee économique pour la rendre autonome sur le réseau Wi-Fi.

1. Le Matériel

2. Fonctionnement de l'architecture

3. Interface de Développement (PHP / JavaScript)

La passerelle Tasmota expose une API HTTP simple. Vous n'avez besoin d'aucun SDK complexe.

Pourquoi cette solution est la meilleure

Note : Cette architecture repose sur le fait que le pont Zigbee flashé maintient l'état des capteurs en mémoire, permettant une interrogation à la demande (polling) par vos scripts quand vous le souhaitez.

Guide : Architecture Domotique Autonome pour Capteurs Zigbee

Objectif

Récupérer les données de température de capteurs Zigbee (type Sonoff SNZB-02) via des scripts personnalisés (PHP/JavaScript), sans abonnement cloud, sans infrastructure serveur permanente (type Raspberry Pi 24h/24) et en maîtrisant totalement le matériel.

La Solution Technique : Passerelle Zigbee "Over-the-Air" (OTA) sous Tasmota

La stratégie la plus intelligente consiste à détourner une passerelle Zigbee économique pour la rendre autonome sur le réseau Wi-Fi.

1. Le Matériel

2. Fonctionnement de l'architecture

3. Interface de Développement (PHP / JavaScript)

La passerelle Tasmota expose une API HTTP simple. Vous n'avez besoin d'aucun SDK complexe.

Pourquoi cette solution est la meilleure

Note : Cette architecture repose sur le fait que le pont Zigbee flashé maintient l'état des capteurs en mémoire, permettant une interrogation à la demande (polling) par vos scripts quand vous le souhaitez.

Rassurez-vous, ce n'est pas si compliqué, mais cela demande de la méthode car il s'agit d'une manipulation matérielle (on appelle cela le flashing initial). Une fois cette étape passée, le serveur Tasmota est directement intégré dans la passerelle et tout se fait ensuite très facilement.

Voici concrètement comment cela se déroule et ce que cela implique :

1. Pourquoi il faut intervenir physiquement au début

À l'achat, la passerelle Sonoff ZBBridge-P est fermée et verrouillée par son fabricant. Elle tourne sous le système officiel eWeLink. Pour y installer Tasmota, la puce ESP32 interne a besoin d'être connectée une toute première fois à un ordinateur pour recevoir le nouveau fichier (le firmware).

2. Le matériel nécessaire pour cette étape initiale

3. Les grandes étapes de l'opération

  1. Ouvrir le boîtier : Retirer les vis ou clips de la passerelle ZBBridge-P.
  2. Brancher les fils : Souder ou maintenir fermement les 4 fils sur les points précis indiqués sur la carte : GND (masse), 3V3 (alimentation), TX (transmission) et RX (réception). Attention à bien croiser les TX/RX (le TX de l'adaptateur sur le RX de la carte).
  3. Mettre en mode flash : Maintenir un petit bouton physique présent sur la carte au moment de brancher l'adaptateur USB à l'ordinateur pour faire passer l'ESP32 en mode écriture.
  4. Envoyer Tasmota : Utiliser un outil de flash (comme l'installeur web officiel de Tasmota via un navigateur compatible Chrome/Edge, ou un logiciel comme Tasmotizer) pour pousser le fichier tasmota32-zbbrdgpro.bin en quelques secondes.

4. La suite : Le mode "Serveur Tasmota" natif

Une fois cette étape terminée, vous débranchez les fils, vous refermez le boîtier, et vous le rebranchez normalement sur une prise murale USB.

À partir de là :

En résumé

Si vous n'avez jamais fait de soudure ou manipulé de petits composants, cela peut paraître intimidant la toute première fois, mais des centaines de tutoriels pas à pas existent pour le ZBBridge-P. C'est le seul "effort" à fournir : un passage obligé unique pour s'affranchir définitivement du cloud et des abonnements. Ensuite, vos scripts PHP/JS pourront dialoguer directement avec elle.

Rassurez-vous, ce n'est pas si compliqué, mais cela demande de la méthode car il s'agit d'une manipulation matérielle (on appelle cela le flashing initial). Une fois cette étape passée, le serveur Tasmota est directement intégré dans la passerelle et tout se fait ensuite très facilement.

Voici concrètement comment cela se déroule et ce que cela implique :

1. Pourquoi il faut intervenir physiquement au début

À l'achat, la passerelle Sonoff ZBBridge-P est fermée et verrouillée par son fabricant. Elle tourne sous le système officiel eWeLink. Pour y installer Tasmota, la puce ESP32 interne a besoin d'être connectée une toute première fois à un ordinateur pour recevoir le nouveau fichier (le firmware).

2. Le matériel nécessaire pour cette étape initiale

3. Les grandes étapes de l'opération

  1. Ouvrir le boîtier : Retirer les vis ou clips de la passerelle ZBBridge-P.
  2. Brancher les fils : Souder ou maintenir fermement les 4 fils sur les points précis indiqués sur la carte : GND (masse), 3V3 (alimentation), TX (transmission) et RX (réception). Attention à bien croiser les TX/RX (le TX de l'adaptateur sur le RX de la carte).
  3. Mettre en mode flash : Maintenir un petit bouton physique présent sur la carte au moment de brancher l'adaptateur USB à l'ordinateur pour faire passer l'ESP32 en mode écriture.
  4. Envoyer Tasmota : Utiliser un outil de flash (comme l'installeur web officiel de Tasmota via un navigateur compatible Chrome/Edge, ou un logiciel comme Tasmotizer) pour pousser le fichier tasmota32-zbbrdgpro.bin en quelques secondes.

4. La suite : Le mode "Serveur Tasmota" natif

Une fois cette étape terminée, vous débranchez les fils, vous refermez le boîtier, et vous le rebranchez normalement sur une prise murale USB.

À partir de là :

En résumé

Si vous n'avez jamais fait de soudure ou manipulé de petits composants, cela peut paraître intimidant la toute première fois, mais des centaines de tutoriels pas à pas existent pour le ZBBridge-P. C'est le seul "effort" à fournir : un passage obligé unique pour s'affranchir définitivement du cloud et des abonnements. Ensuite, vos scripts PHP/JS pourront dialoguer directement avec elle.

C'est tout à fait compréhensible. Ouvrir un boîtier et manipuler des fils électriques ou des soudures pour un premier flashage peut en effet être intimidant et stresse à l'idée d'endommager le matériel. Pour répondre précisément à vos deux questions :

1. Existe-t-il des passerelles vendues directement avec Tasmota préinstallé ?

Oui. Certains revendeurs spécialisés (souvent sur des plateformes comme AliExpress ou des boutiques dédiées à la domotique alternative) proposent des passerelles déjà flashées en usine. Par exemple, la passerelle ZB-GW03 (un pont Zigbee Ethernet/Wi-Fi basé sur ESP32) est parfois vendue pré-configurée avec le firmware Tasmota MQTT. Vous la recevez, vous la branchez simplement sur votre box internet ou en Wi-Fi, et Tasmota est immédiatement opérationnel, sans aucune manipulation délicate de votre part.

2. Peut-on connecter une passerelle directement à un ordinateur ou une tablette ?

Si vous ne voulez pas passer par le réseau Wi-Fi de la maison pour interroger vos capteurs et que vous préférez un lien direct, il existe une alternative beaucoup plus simple et sans risque de soudure : la clé USB Zigbee directe.

C'est tout à fait compréhensible. Ouvrir un boîtier et manipuler des fils électriques ou des soudures pour un premier flashage peut en effet être intimidant et stresse à l'idée d'endommager le matériel. Pour répondre précisément à vos deux questions :

1. Existe-t-il des passerelles vendues directement avec Tasmota préinstallé ?

Oui. Certains revendeurs spécialisés (souvent sur des plateformes comme AliExpress ou des boutiques dédiées à la domotique alternative) proposent des passerelles déjà flashées en usine. Par exemple, la passerelle ZB-GW03 (un pont Zigbee Ethernet/Wi-Fi basé sur ESP32) est parfois vendue pré-configurée avec le firmware Tasmota MQTT. Vous la recevez, vous la branchez simplement sur votre box internet ou en Wi-Fi, et Tasmota est immédiatement opérationnel, sans aucune manipulation délicate de votre part.

2. Peut-on connecter une passerelle directement à un ordinateur ou une tablette ?

Si vous ne voulez pas passer par le réseau Wi-Fi de la maison pour interroger vos capteurs et que vous préférez un lien direct, il existe une alternative beaucoup plus simple et sans risque de soudure : la clé USB Zigbee directe.