De la collecte des capteurs au contrôle en temps réel sur mobile, un système IoT complet pour l'agriculture intelligente.
Deux cartes de développement à tâches distinctes, relayage MQTT, terminal HarmonyOS pleinement fonctionnel.
SmartShed est un système IoT d’agriculture intelligente couvrant toute la chaîne, de la perception en serre à la commande depuis un téléphone. Deux cartes Hi3861 sous OpenHarmony assurent respectivement l’acquisition des capteurs et la commande des actionneurs, en relayant les messages via un service MQTT EMQX ; une application HarmonyOS affiche température, humidité, luminosité et humidité du sol, et fournit la gestion à distance.
La gestion d’une serre exige une chaîne de messages stable entre acquisition et commande, ainsi que la possibilité de basculer entre modes manuel et automatique. Ce projet relie la perception environnementale, l’actionnement du sol et l’exploitation depuis le téléphone en un système de bout en bout.
La carte RGB assure l’acquisition des données environnementales et la carte SOI la commande des actionneurs ; chacune exécute OpenHarmony et se connecte au même service MQTT. Les données montantes et les commandes descendantes sont séparées par des topics convenus.
Les cartes exécutent OpenHarmony LiteOS-M en C. La couche de messages repose sur le publish/subscribe MQTT d’EMQX. L’application est une application HarmonyOS écrite en ArkTS / ArkUI, incluant un client MQTT implémenté maison et une interface HDS.
Les deux dépôts, embarqué et application, ainsi que le rapport de cours, sont publics. La page documente le flux de données, la correspondance matérielle, la conception des threads et l’adaptation à la forme Glass. La reproduction physique exige les capteurs, actionneurs, réseau et configuration de broker correspondants.
Rapport de conception du cours du second semestre de l'année 2025-2026, présenté par : Chen Zirui (Ray Chen)
Smart Shed (Serre Intelligente) est un système complet de contrôle IoT pour l'agriculture intelligente, basé sur OpenHarmony et HarmonyOS NEXT de Huawei. En bref : deux cartes de développement s'occupent de percevoir et de contrôler les paramètres environnementaux, communiquent en temps réel avec l'application mobile via le protocole MQTT, et permettent finalement le monitoring automatique et le pilotage intelligent de la température, de l'humidité, de la luminosité et de l'humidité du sol dans la serre.
OpenHarmony + Hi3861 × 2
Collecte capteurs & contrôle actionneurs
EMQX MQTT Broker
Relayage de messages & routage par Topic
HarmonyOS NEXT (API23)
Mate 70 Pro+ / MatePad Pro
Architecture globale, défis techniques rencontrés, innovations apportées
Côté embarqué collecte les données → Serveur relaie les messages → Mobile affiche et contrôle
OpenHarmony 1.0 Release
Rayawa/rgb @ HiSilicon-Hi3861
Rayawa/soi @ HiSilicon-Hi3861
Collecte capteurs + affichage OLED
Contrôle PWM/GPIO des actionneurs
MQTT 5.0 WebSocket
wss://broker.emqx.io:8084
@MQTTX
Relayage de messages public
Routage distribué par Topic
HarmonyOS 6.1.0 (API23)
Smart Shed @ Mate 70 Pro+
Smart Shed @ MatePad Pro 12.2
Affichage de données en temps réel
Modes Manuel / Intelligent
Problèmes réellement rencontrés durant le développement
Carte de perception environnementale (RGB) et carte d'exécution sol (SOI) isolées physiquement et découplées logiquement : chacune gère son domaine tout en collaborant.
Côté HarmonyOS, les paquets MQTT sont entièrement construits manuellement depuis TCP Socket, sans aucune dépendance tierce.
Intégration de la bibliothèque officielle HarmonyOS Design System : navigation immersive, effets gravitationnels, arrière-plan lumineux.
Mode Manuel : ajustement libre des niveaux. Mode Intelligent : décision automatique selon les seuils, thread résident sécurisé en arrière-plan.
Application supplémentaire sous forme Glass pour montre connectée, avec matériaux immersifs et animations gazeuses.
Détection automatique hors ligne (timeout 5s), reconnexion avec recul exponentiel, bus de journalisation GlobalLogBus comme filet de sécurité global.
Principe de l'architecture Pub/Sub et conception du flux de données
MQTT est un protocole léger de messagerie, conçu spécifiquement pour les scénarios IoT à faible bande passante
Le côté embarqué Hi3861 agit en tant qu'émetteur, encapsule les données des capteurs en JSON et les envoie vers le Topic désigné.
EMQX agit en tant que Broker MQTT : après réception d'un message, il le transfère aux abonnés correspondants selon les règles de Topic.
L'application HarmonyOS, une fois abonnée aux Topics concernés, reçoit les données des capteurs et peut également envoyer des commandes de contrôle.
Comment les données transitent du matériel jusqu'au mobile, et comment les commandes reviennent vers le matériel pour exécution
Les capteurs de la carte d'extension collectent les données brutes → lecture ADC de luminosité/humidité du sol, lecture I2C de AHT20 température/humidité
Le Hi3861 convertit les données en format JSON et les envoie au Broker EMQX via un paquet MQTT PUBLISH
EMQX reçoit le message et le distribue aux clients abonnés selon les règles de Topic
HarmonyOS reçoit et analyse le message → mise à jour d'état via @StorageLink → rafraîchissement des chiffres UI / jugement des seuils en mode intelligent
Mode Manuel : glisser le curseur pour régler le niveau. Mode Intelligent : génération automatique de commande si dépassement de seuil
HarmonyOS convertit la commande de contrôle en paquet MQTT, qui est distribué via EMQX
Après réception du message, le Hi3861 analyse le sujet et le contenu → contrôle des sorties GPIO/PWM → actionnement ventilateur/pompe/lumière
OpenHarmony LiteOS-M + multithread CMSIS-RTOS, développement entièrement en C
Responsable de « voir l'environnement » et « afficher localement »
OLED SSD1306 (128×64) avec rafraîchissement en temps réel des données de température, humidité et luminosité
Responsable de « mesurer le sol » et « agir »
Grandes fonctions séparées, petits modules divisés : clair et facile à maintenir
Connexion Wi-Fi, communication MQTT, pilote OLED : tout est ici. Le mutex I2C est aussi géré ici pour éviter que plusieurs threads ne s'accaparent le bus.
Divisée en deux sous-répertoires :
Les fichiers de build .gn des deux cartes sont gérés de manière unifiée. La compilation conditionnelle active dynamiquement les modules selon la carte : ajouter une nouvelle carte = ajouter simplement un fichier gn.
CMSIS-RTOS gère les tâches parallèles sous le noyau temps réel LiteOS-M
smart_shed_all.c, avec une pile de 8 KoChaque module fonctionnel tourne indépendamment dans le noyau LiteOS, avec son propre espace de pile (4Ko~8Ko) et sa priorité, sans blocage mutuel :
AHT20 / I2C
Échantillonnage ADC
Échantillonnage ADC
Contrôle GPIO/PWM
Rendu SSD1306
Publication/Abonnement Paho
Le capteur AHT20 et l'écran OLED partagent le même bus I2C0 (GPIO13 & GPIO14). Si deux threads y accèdent simultanément, ça coince. Solution :
Le thread de collecte temp./humid. et le thread de rafraîchissement OLED lisent et écrivent simultanément sur I2C0, provoquant une corruption des données
Utiliser le mutex i2c0_lock/unlock : verrouillage/déverrouillage avant et après chaque lecture/écriture, garantissant qu'un seul périphérique occupe le bus à un instant donné
I2C0-0x78 GPIO13&14
oled_ssd1306.c
ADC_CH4
soil_moisture_task.c
P06
water_pump_task.c
P08
fan_task.c
I2C0-0x78 GPIO13&14
oled_ssd1306.c
I2C0-0x44
temp_and_hum_task.c
ADC_CH4
light_intensity_task.c
GPIO10/11/12=>PWM1/2/3
led_task.c
Connexion Wi-Fi → TCP établi → MQTT envoie/reçoit → Les actionneurs bougent
Connexion au SSID "Rayawa", obtention d'une IP via DHCP puis passage en communication TCP lwIP
La bibliothèque Paho gère uniquement l'encodage/décodage des paquets ; le cycle de vie complet du Socket TCP doit être géré manuellement
Les données des capteurs sont transmises au Broker EMQX au format JSON
Réception d'un paquet PUBLISH → analyse du sujet et de la charge utile via MQTTDeserialize_publish() → définition des variables globales via mqtt_apply_command(). Les threads d'actionneurs lisent continuellement ces variables pour contrôler les sorties GPIO/PWM, faisant fonctionner ventilateur, pompe, etc.
ArkTS · Modèle Stage · Visuels avancés HDS · Client MQTT auto-implémenté
Terminal de contrôle pleinement fonctionnel tournant sur Mate 70 Pro+ et MatePad Pro
Glisser le curseur pour régler ventilateur (0-3 niveaux), pompe (0-3 niveaux), lumière complémentaire (0-100%). Synchronisation automatique du niveau actuel vers la carte à l'entrée de page, support retour haptique.
Définir les seuils min/max de température, humidité, luminosité et humidité du sol. Polling périodique des données capteurs, déclenchement automatique du contrôle en cas de dépassement. Thread résident en arrière-plan, destruction sécurisée à la sortie de page contre les fuites mémoire.
Callback MQTT réceptionnant les données capteurs, gestion d'état @StorageLink pilotant le rafraîchissement automatique des chiffres ArkUI.
Bus d'événements GlobalLogBus enregistrant l'état de communication, les actions utilisateur et les messages d'erreur, pratique pour diagnostiquer les problèmes.
Architecture en couches basée sur ArkTS
Point d'entrée unifié pour les ressources globales de l'application et les scripts de build Hvigor.
Couche UI construite en ArkTS, incluant l'interface complète des modes Manuel/Intelligent et du panneau de debug.
Encapsulation du client MQTT (MqttReceiverClient.ts), connexion directe TCP Socket pour communication bidirectionnelle, zéro dépendance tierce.
Structures de données centrales et modèles d'état, assurant la liaison réactive entre UI et données.
Côté HarmonyOS, aucune bibliothèque MQTT tierce n'a été utilisée : les paquets ont été entièrement construits à la main depuis TCP Socket. Cela donne un contrôle total sur l'ensemble du processus de communication, et facilite grandement le diagnostic en cas de problème.
Gestion centralisée des niveaux de ventilateur, pompe et luminosité LED, partage d'état inter-pages via @StorageLink.
Données capteurs et commandes de contrôle transmises de manière fiable via un format unifié dans la couche MQTT.
GlobalLogBus collecte de manière unifiée l'état de communication, les enregistrements d'opérations et les informations d'anomalies.
Création de la connexion à l'entrée de page, destruction du thread et libération des ressources à la sortie : zéro fuite mémoire.
Une interface fonctionnelle et soignée
Navigation supérieure immersive à champ lumineux, effet flou glassmorphism
Déformation élastique à l'appui + diffusion du champ lumineux en retour tactile
Entrée échelonnée avec délai, courbe ressort pour une expérience fluide
Arrière-plan lumineux fluide traversant toute l'interface, ambiance maximale en mode sombre
Adaptation tablette en double colonne, équilibre entre densité d'information et harmonie visuelle
Effet de champ gravitationnel lors des transitions de page, animations d'attraction/répulsion naturelles entre éléments.
Arrière-plan lumineux fluide + champ lumineux global sombre double colonne, ombres dynamiques variant avec les interactions.
Fondu + animation élastique, courbe SpringMotion pour des transitions soyeuses.
Système de grille responsive ArkUI, adaptation automatique aux deux facteurs de forme mobile et tablette :
Colonne unique défilement vertical, cartes empilées
Double colonne côte à côte, exploitation optimale de l'espace large
Forme montre connectée — Matériaux immersifs + Animations gazeuses
Système de composants boutons personnalisés basé sur les spécifications HDS, unifiant l'apparence visuelle et le retour tactile de tous les éléments interactifs sous la forme Glass. Supporte plusieurs tailles et styles d'état (par défaut/appuyé/désactivé), agréable à utiliser sur petit écran.
Ce que vous vous posez peut-être, et ce que ce projet m'a apporté
OpenHarmony offre un vrai RTOS (LiteOS-M) avec ordonnancement préemptif, gestion multithread native et un écosystème matériel Huawei mature. Arduino/ESP32 convient au prototypage ; ce projet met l’accent sur le multitâche, les mutex, les piles configurables et la compilation conditionnelle. Et puis, travailler avec un système d'exploitation complet plutôt qu'un simple framework, c'est une expérience d'apprentissage totalement différente.
Environ 6 semaines au total : 2 semaines pour la partie embarquée (drivers, multithread, MQTT), 3 semaines pour l'App HarmonyOS (refonte complète depuis JavaUI API7 vers ArkTS API23, implémentation MQTT from scratch, design HDS), et 1 semaine pour l'intégration, les tests et la rédaction du rapport. Le plus long a été la refonte côté application — le code legacy était vraiment difficile à migrer.
Sans hésiter : le conflit de bus I2C. AHT20 et SSD1306 partagent le même bus I2C0, et quand le thread de collecte et celui d'affichage y accèdent en même temps, c'est le chaos. La solution paraît simple (un mutex), mais trouver la source du bug a pris presque 2 jours de debug avec un oscilloscope logique. Ensuite, écrire un client MQTT entier depuis zéro en ArkTS a aussi été un bon défi — surtout la gestion de la reconnexion et du cycle de vie des threads.
Côté embarqué : oscilloscope logique USB pour tracer le bus I2C, serial print sur UART0 pour les logs, et MQTTX pour visualiser les messages en temps réel. Côté HarmonyOS : DevEco Studio avec son debugger intégré, HiLog pour les logs système, et le panneau GlobalLogBus intégré à l'App pour suivre toute l'activité MQTT en direct. L'outil le plus précieux ? Probablement MQTTX — pouvoir voir exactement ce qui passe sur le broker en temps réel a sauvé pas mal de soirées.
Pour un prototype de cours, il est déjà assez abouti. Mais pour un déploiement réel, il manque quelques choses : authentification MQTT (actuellement sans mot de passe), persistance des seuils de mode intelligent (stockés en mémoire volatile), et une UI de configuration initiale (SSID/mot de passe WiFi actuellement codés en dur). Le hardware aussi : le Hi3861 n'est pas certifié industriel, et les capteurs bas coût manquent de calibration. Mais l'architecture logicielle est solide — ces améliorations seraient relativement simples à intégrer.
Beaucoup plus que prévu. Sur le plan technique : programmation système embarquée, RTOS, protocoles IoT, développement d'application mobile moderne. Sur le plan méthodologique : comment architecturer un système distribué de bout en bout, gérer la complexité avec des couches propres, et documenter correctement. Et surtout : la patience face aux bugs matériels qui ne s'expliquent pas, et la satisfaction de voir un système complet fonctionner de bout en bout — du capteur jusqu'à l'écran du téléphone.
De la première ligne de code à la présentation finale, SmartShed a été un voyage complet à travers l'écosystème HarmonyOS/OpenHarmony. J'ai touché à presque chaque couche d'un système IoT : drivers matériels, RTOS, protocoles réseau, développement d'application mobile, design d'interface utilisateur, et même un peu de devOps avec la chaîne de build GN/Ninja.
Si je devais retenir une chose, c'est que la complexité se gère par l'architecture. Au début, j'ai essayé de tout mettre dans un seul fichier — résultat : cauchemar de maintenance. Après refactorisation en couches (common/modules/boards) et adoption du modèle Stage côté App, chaque modification devient ciblée et prévisible.
Merci d'avoir lu jusqu'ici. Si ce projet vous inspire ou si vous avez des questions, n'hésitez pas à me contacter ou à explorer le code source sur GitHub — il est entièrement open-source.