SmartShed — Serre Intelligente
Un système IoT complet de contrôle de serre intelligente.
De la collecte des données capteurs au contrôle en temps réel sur mobile, toute la chaîne est implémentée en autonomie.
Architecture duale de cartes
La carte de détection environnementale collecte température, humidité et luminosité ; la carte d'action sol commande ventilateur et pompe. Deux cartes Hi3861 fonctionnent indépendamment et collaborent.
Client MQTT auto-implémenté
Côté HarmonyOS, aucune dépendance à une bibliothèque tierce : les paquets protocole MQTT sont construits manuellement depuis TCP Socket.
Commutation bimode
Mode Manuel : ajustement libre de chaque niveau d'appareil. Mode Automatique : exécution automatique des stratégies selon les données capteurs.
Prix OpenAtom
Reconnu dans le concours OpenAtom pour le sujet « Serre intelligente basée sur OpenHarmony ».
Comment ça marche
Trois couches : collecte matérielle → relayage cloud → contrôle mobile
Côté embarqué
Hi3861 × 2
Collecte capteurs + affichage OLED
Contrôle PWM/GPIO
EMQX Broker
MQTT 3.1.1
Relayage de messages public
Routage par Topic
HarmonyOS App
Mate 70 Pro+ / iPad
Affichage de données en temps réel
Modes Manuel / Automatique
Côté embarqué : deux cartes, chacune avec une mission
Basé sur OpenHarmony LiteOS-M + multithread CMSIS-RTOS, développé entièrement en C
Carte de détection environnementale (env_rgb_board)
Responsable de « voir » et « afficher »
- AHT20 — Lecture I2C de température et humidité
- Capteur de luminosité — Échantillonnage ADC (0~4095)
- LED RGB de complément lumineux — Contrôle PWM (0~100%)
- LEDs d'état — GPIO 11(vert) / GPIO 12(jaune)
Écran OLED SSD1306 (128×64) avec rafraîchissement en temps réel des données de température, humidité et luminosité
Carte d'action sol (soil_actuator_board)
Responsable de « percevoir le sol » et « exécuter l'action »
- Capteur d'humidité du sol — Échantillonnage ADC de la teneur en eau
- Ventilateur CC — PWM quatre niveaux (arrêt/bas/moyen/haut)
- Pompe submersible — GPIO quatre niveaux (off/petit/moyen/grand)
Ordonnancement des tâches multithread
CMSIS-RTOS gère 4 threads parallèles, mutex protégeant les ressources partagées :
Échantillonnage ADC/I2C chaque seconde
Rendu des données vers l'écran
JSON → EMQX Broker
Commande → PWM/GPIO
Côté application : terminal de contrôle complet HarmonyOS NEXT
100% ArkTS · Effets visuels avancés HDS · Client MQTT auto-implémenté
Design UI : pas seulement fonctionnel, mais aussi beau
Intégration de la bibliothèque officielle de composants visuels avancés HarmonyOS Design System (HDS) :
Navigation supérieure immersive à effet de champ lumineux, transition naturelle de fusion d'arrière-plan
Déformation élastique + diffusion de champ lumineux lors de l'appui sur les boutons
Animation courbe spring par étapes retardées, hiérarchie visuelle maximale
Mode Personnalisé (ManualPage)
Contrôlez comme vous voulez
- Ajustement par glissement de curseur : ventilateur (0-3 niveaux) / pompe (0-3 niveaux) / LED de complément (0-100%)
- Synchronisation automatique des niveaux actuels vers la carte de développement à l'entrée de page
- Support retour haptique avec interrupteur de vibration
Mode Intelligent (AutoPage)
Laissez le système décider
- Configuration des seuils min/max pour température / humidité / luminosité / humidité du sol
- Polling périodique des données capteurs, déclenchement automatique du contrôle si dépassement des seuils
- Thread résident en arrière-plan (autoManagerThread), destruction sécurisée à la sortie de page contre les fuites mémoire
Point technique marquant : implémenter un client MQTT depuis zéro
Côté HarmonyOS, aucune bibliothèque MQTT tierce n'est utilisée. Les paquets protocole sont construits manuellement depuis TCP Socket :
- Assemblage manuel Fixed Header + Variable Header + Payload
- Implémentation complète des paquets CONNECT / PUBLISH / SUBSCRIBE / PINGREQ
- Heartbeat KeepAlive tous les 60s
- Reconnexion automatique en cas de coupure + stratégie de recul exponentiel
- Connexion TCP unique, abonnement multi-Topic et routage distribué
- Gestion d'état @StorageLink et découplage réactif ArkUI
Le bug rencontré & comment je l'ai corrigé
Lorsque le callback MQTT asynchrone retourne de nouvelles données, @ObjectLink d'ArkUI n'écoute que les changements de propriétés du premier niveau de l'objet. Résultat : les valeurs numériques des capteurs ne se mettent pas à jour, et les curseurs sont bloqués impossibles à faire glisser.
this.zone1 = { ...this.zone1 }
Utiliser une copie superficielle par déstructuration pour forcer la création d'une nouvelle référence d'objet, perçant la machine à états pour déclencher le rafraîchissement UI. Une seule ligne de code pour corriger un bug critique.
Comment les données circulent
Deux canaux unidirectionnels : les données capteurs montent, les commandes de contrôle descendent
Montant : collecte de données → affichage mobile
① Échantillonnage capteurs
Lecture ADC de luminosité / humidité du sol, lecture I2C de AHT20 température/humidité
② Affichage OLED local
Écran SSD1306 rafraîchissant les données en temps réel (visible même sans connexion mobile)
③ Encapsulation JSON & publication
Payload allégé comme {"intensity": 450}, publication via Paho MQTT vers EMQX
④ Analyse App & rafraîchissement UI
Callback MQTT → copie superficielle → déclenchement de la mise à jour de l'affichage numérique par machine à états ArkUI
Descendant : action utilisateur → exécution matérielle
① Action utilisateur ou stratégie automatique
Glissement manuel de curseur / déclenchement par jugement de seuil en mode intelligent
② Construction & envoi du paquet MQTT
Le client auto-implémenté assemble manuellement le paquet PUBLISH, envoi via EMQX
③ Réception Hi3861 & exécution
Analyse du callback MQTT → régulation PWM ventilateur/LED, contrôle GPIO pompe
Conception fiabilité
Timeout de 5 secondes sans réception de données = carte considérée hors ligne
L'UI bascule automatiquement en état désactivé gris + invitation à reconnecter
Reprise automatique de l'abonnement aux Topics après rétablissement
Bus d'événements GlobalLogBus enregistrant toutes les opérations
État de communication MQTT / actions utilisateur / messages d'erreur
Pratique pour le debug et le diagnostic des problèmes
Protocole de communication : conception des Topics MQTT
Espaces de noms séparés par carte, transmission légère QoS 0
Montant : remontée des données capteurs
Descendant : envoi des commandes de contrôle
Optimisation des performances
- Payload JSON allégé — Suppression des imbrications redondantes, réduction de la latence de transmission publique et du taux de perte de paquets
- Architecture plane à partition unique — Concentration de la concurrence haute fréquence sur une communication à nœud unique, allégeant la charge instantanée de handshake du Broker