From sensor data acquisition to real-time mobile control — a complete smart agriculture IoT system.
Two dev boards each doing their job, MQTT message relay, a full-featured HarmonyOS terminal.
SmartShed is an IoT system for smart agriculture covering the full chain from greenhouse sensing to phone control. Two Hi3861 boards running OpenHarmony handle sensor acquisition and actuator control respectively, relaying messages through an EMQX MQTT service; a HarmonyOS application displays temperature, humidity, light and soil moisture, and provides remote management.
Greenhouse management requires a stable message chain between acquisition and control, along with the ability to switch between manual and automatic modes. This project connects environmental sensing, soil actuation and phone-side operation into one end-to-end system.
The RGB board handles environmental data acquisition and the SOI board handles actuator control; each runs OpenHarmony and connects to the same MQTT service. Upstream data and downstream commands are separated by agreed topics.
The boards run OpenHarmony LiteOS-M with C. The message layer is EMQX MQTT publish/subscribe. The application is a HarmonyOS app written in ArkTS / ArkUI, including a self-implemented MQTT client and an HDS interface.
Both the embedded and application repositories, along with the course report, are public. The page documents the data flow, hardware mapping, threading design and Glass form adaptation. Physical reproduction requires the corresponding sensors, actuators, network and broker configuration.
Course Design Report for 2025-2026 Spring Semester — Presented by Ray Chen (Chen Zirui)
Smart Shed (Smart Greenhouse) is a smart agriculture IoT control system built on Open Source OpenHarmony and Huawei HarmonyOS NEXT. Simply put: two development boards handle sensing and controlling environmental parameters, communicating in real-time with a mobile app via MQTT, ultimately achieving automatic monitoring and intelligent regulation of temperature, humidity, light intensity, and soil moisture inside the greenhouse.
OpenHarmony + Hi3861 × 2
Sensor sampling & actuator control
EMQX MQTT Broker
Message relay & Topic routing dispatch
HarmonyOS NEXT (API23)
Mate 70 Pro+ / MatePad Pro
Overall architecture, challenges faced, and innovations made
Embedded side collects data → Server side relays messages → Mobile side displays and controls
OpenHarmony 1.0 Release
Rayawa/rgb @ HiSilicon-Hi3861
Rayawa/soi @ HiSilicon-Hi3861
Sensor sampling + OLED display
PWM/GPIO actuator control
MQTT 5.0 WebSocket
wss://broker.emqx.io:8084
@MQTTX
Public network message relay
Topic routing dispatch
HarmonyOS 6.1.0 (API23)
Smart Shed @ Mate 70 Pro+
Smart Shed @ MatePad Pro 12.2
Real-time data display
Manual / Smart dual-mode
Problems actually encountered during development
The environment sensing board (RGB) and soil actuation board (SOI) are physically isolated and logically decoupled — each handles its own duties while working together seamlessly.
The HarmonyOS side builds MQTT packets entirely from scratch starting from TCP Socket — zero third-party library dependencies.
Integrated HarmonyOS official Design System component library: immersive navigation, gravity animations, light-field backgrounds.
Manual mode gives you free adjustment of levels; Smart mode makes automatic decisions based on thresholds, with a background thread running safely at all times.
Built an additional watch-side Glass app form factor with immersive materials and gaseous animation effects.
Auto offline detection (5s timeout), exponential backoff reconnection on disconnect, GlobalLogBus logging bus as a comprehensive safety net.
Pub/Sub architecture principles and data flow design
MQTT is a lightweight messaging protocol purpose-built for low-bandwidth IoT scenarios
The embedded Hi3861 acts as publisher, packaging sensor data into JSON and sending it to designated Topics.
EMQX serves as the MQTT Broker, receiving messages and forwarding them to corresponding subscribers per Topic rules.
The HarmonyOS App receives sensor data after subscribing to relevant Topics, and can also issue control commands.
How data travels from hardware all the way to your phone, and how operations get sent back to hardware for execution
Sensors on the expansion board collect raw data → ADC reads light/soil moisture, I2C reads AHT20 temp & humidity
Hi3861 converts data to JSON format and sends it to EMQX Broker via MQTT PUBLISH packet
Upon receiving the message, EMQX distributes it to subscribed clients according to Topic rules
HarmonyOS receives and parses the message → @StorageLink updates state → UI numbers refresh / Smart mode evaluates thresholds
Drag sliders to adjust levels in manual mode, or threshold exceeded in Smart mode auto-generates control commands
HarmonyOS converts control commands into MQTT packets, dispatched through EMQX
Hi3861 parses topic and payload upon receiving the message → controls GPIO/PWM output → fan/water pump/grow light activates
OpenHarmony LiteOS-M + CMSIS-RTOS multi-threading, developed in pure C
Responsible for "seeing the environment" and "local display"
SSD1306 OLED (128×64) refreshes temperature, humidity, and light data in real time
Responsible for "sensing soil" and "getting work done"
Big picture split by function, details split by module — clean and maintainable
Wi-Fi connection, MQTT communication, OLED drivers all live here. I2C mutex lock is also managed here to prevent multiple threads from fighting over the bus.
Split into two subdirectories:
Unified management of .gn build files for both dev boards. Conditional compilation dynamically enables modules per board config — adding a new board just means adding one gn file.
CMSIS-RTOS manages parallel tasks under the LiteOS-M real-time kernel
smart_shed_all.c, stack size 8KBEach functional module runs independently inside the LiteOS kernel, each with its own stack space (4KB~8KB) and priority — none block each other:
AHT20 / I2C
ADC Sampling
ADC Sampling
GPIO/PWM Control
SSD1306 Rendering
Paho Publish/Subscribe
The AHT20 temperature/humidity sensor and OLED display share the same I2C0 bus (GPIO13 & GPIO14). If two threads access it simultaneously, things break. The solution:
The temp/humidity sampling thread and OLED refresh thread read/write I2C0 simultaneously, causing data corruption
Use i2c0_lock/unlock mutex lock, acquire before every read/write and release after — guarantees only one device occupies the bus at any given moment
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
Connect Wi-Fi → TCP established → MQTT sends/receives → actuators spring to action
Connect to SSID "Rayawa", get IP via DHCP then enter lwIP TCP communication
Paho library only handles packet encoding/decoding; the full TCP Socket lifecycle must be managed manually
Sensor data reported to EMQX Broker in JSON format
Upon receiving a PUBLISH packet, parse topic and payload using MQTTDeserialize_publish(), then set global variables via mqtt_apply_command(). Actuator threads continuously read these variables to control GPIO/PWM, driving fans, pumps, and other devices
ArkTS · Stage Model · HDS Advanced Visuals · Self-Implemented MQTT Client
A full-featured control terminal running on Mate 70 Pro+ and MatePad Pro
Drag sliders to adjust fan (0-3 levels), water pump (0-3 levels), grow light (0-100%). Auto-syncs current levels to the dev board when entering the page, supports haptic feedback.
Set upper/lower threshold limits for temperature/humidity/light/soil moisture. Periodically polls sensor data and auto-triggers control when out of range. Background resident thread, safely destroyed on page exit to prevent leaks.
MQTT callback receives sensor data, @StorageLink state management drives ArkUI auto-refresh of displayed numbers.
GlobalLogBus event bus records communication status, user actions, and error info for easy troubleshooting.
Layered architecture built on ArkTS
Unified entry point for app-level global resources and Hvigor build scripts.
ArkTS-built UI layer, containing complete interfaces for manual/smart dual-mode and debug panel.
Encapsulates MQTT client (MqttReceiverClient.ts), TCP Socket direct connection for bidirectional communication, zero third-party dependencies.
Core data structures and state models ensuring reactive binding between UI and data.
The HarmonyOS side uses zero third-party MQTT libraries — it hand-crafts packets entirely from scratch starting at TCP Socket level. This gives complete control over the entire communication process, making issues much easier to diagnose.
Centrally manages fan levels, pump levels, grow light brightness; @StorageLink shares state across pages.
Sensor data and control commands transmitted reliably over MQTT layer in unified format.
GlobalLogBus uniformly collects communication status, operation records, and exception info.
Create connection on page enter, destroy threads and release resources on page exit — zero memory leaks.
Not just functional — it has to look good too
Immersive light-field top navigation with frosted glass blur effect
Elastic deformation on button press + light field diffusion feedback
Staggered delay entry, spring-curve animations for smooth onboarding experience
Flowing light background runs through the entire interface, dark mode atmosphere maxed out
Tablet-adaptive dual-column layout balancing information density and visual harmony
Gravity field effects during page transitions, natural attraction-repulsion animations between elements.
Flowing light background + dual-column dark global light field, dynamic light/shadow flows with interaction changes.
Fade in/out + elastic animations, SpringMotion spring-curve silky transitions.
ArkUI responsive grid system automatically adapts to phone and tablet form factors:
Single-column vertical scroll, stacked card display
Dual-column side-by-side, making full use of widescreen space
Smartwatch form factor — immersive materials + gaseous animations
Custom button component system based on HDS specifications, unifying visual presentation and touch feedback for all interactive elements in Glass form. Supports multiple sizes and state styles (default/pressed/disabled), works great on small screens too.
What you might be wondering, and what this project gave me
OpenHarmony gives you a real RTOS (LiteOS-M) with preemptive scheduling, native multithreading and a mature Huawei hardware ecosystem. Arduino / ESP32 is fine for prototyping; this project is about multitasking, mutexes, configurable stacks and conditional compilation. And working with a full operating system rather than a framework is a completely different learning experience.
About 6 weeks in total: 2 weeks on the embedded side (drivers, multithreading, MQTT), 3 weeks on the HarmonyOS app (a full rewrite from JavaUI API7 to ArkTS API23, an MQTT client written from scratch, HDS design), and 1 week for integration, testing and the report. The app rewrite took the longest — the legacy code was genuinely hard to migrate.
The I2C bus conflict, without hesitation. The AHT20 and the SSD1306 share the same I2C0 bus, and when the sampling thread and the display thread hit it at the same time it turns into chaos. The fix looks trivial (add a mutex), but finding the cause took nearly two days with a logic analyser. Writing a complete MQTT client from scratch in ArkTS came second — reconnection and thread lifecycle especially.
Embedded side: a USB logic analyser to trace the I2C bus, serial print over UART0 for logs, and MQTTX to watch messages live. HarmonyOS side: DevEco Studio’s built-in debugger, HiLog for system logs, and the GlobalLogBus panel built into the app to follow all MQTT activity in real time. Most valuable? Probably MQTTX — seeing exactly what passes over the broker in real time saved quite a few evenings.
As a course prototype it is fairly complete. For real deployment a few things are missing: MQTT authentication (there is no password right now), persistence for the smart-mode thresholds (currently held in volatile memory), and an initial setup UI (the WiFi SSID and password are hard-coded). On the hardware side, the Hi3861 is not industrially certified and the low-cost sensors lack calibration. The software architecture is solid though — these would slot in fairly easily.
Much more than expected. Technically: embedded systems programming, RTOS, IoT protocols, modern mobile app development. Methodologically: how to architect a distributed system end to end, how to manage complexity with clean layers, and how to document it properly. And above all: patience with hardware bugs that make no sense, and the satisfaction of seeing a complete system run end to end — from the sensor to the phone screen.
From the first line of code to the final defence, SmartShed was a complete journey through the HarmonyOS / OpenHarmony ecosystem. I touched almost every layer of an IoT system: hardware drivers, RTOS, network protocols, mobile app development, interface design, and even a bit of build-chain (GN / Ninja) engineering.
If I had to keep one lesson, it is that complexity is managed through architecture. At first I tried to put everything in a single file — the result was a maintenance nightmare. After refactoring into layers (common / modules / boards) and adopting the Stage model on the app side, every change became targeted and predictable.
Thanks for reading this far. If the project inspires you or you have questions, feel free to get in touch, or explore the source on GitHub — it is fully open-source.