它要解决什么
温室管理需要在采集与控制之间建立稳定的消息链路，并支持手动与智能两种模式的切换。本项目将环境采集、土壤执行与手机端操作连接为一套端到端系统。
基于Hi3861的智慧大棚系统
—— 开源鸿蒙赋能智慧农业
从传感器采集到手机端实时控制，一套完整的智慧农业物联网系统。
两块开发板各司其职，MQTT 消息中转，HarmonyOS 全功能终端。
项目速览
SmartShed 是一套面向智慧农业的物联网系统，覆盖从温室感知到手机控制的完整链路。两块运行 OpenHarmony 的 Hi3861 开发板分别承担传感器采集与执行器控制，通过 EMQX 的 MQTT 服务中转消息；HarmonyOS 应用展示温湿度、光照与土壤水分，并提供远程管理入口。
- 双板分工采集和控制在不同 Hi3861 节点上完成。
- 实时消息链MQTT Topic 将板端状态和应用操作连接起来。
- 端到端资料嵌入式、应用两个仓库及报告均可查阅。
关于这个项目
两块板如何分工
RGB 板负责环境数据采集，SOI 板负责执行器控制，两块板各自运行 OpenHarmony 并接入同一个 MQTT 服务端。上行数据与下行指令通过约定的 Topic 分隔。
用到什么
板端使用 OpenHarmony LiteOS-M 与 C 语言；消息层为 EMQX 的 MQTT 发布订阅；应用端为 ArkTS / ArkUI 编写的 HarmonyOS 应用，包含自行实现的 MQTT 客户端与 HDS 界面。
当前进展
嵌入式与应用两个仓库及课程报告均已公开，页面收录数据流、硬件映射、线程设计与 Glass 形态适配。实物复现需要对应的传感器、执行器、网络环境与 broker 配置。
项目总体介绍
2025-2026 学年第二学期课程设计报告，汇报人：陈梓睿（Ray Chen）
什么是 Smart Shed？
Smart Shed（智慧大棚）是一套基于开源鸿蒙 OpenHarmony和华为鸿蒙 HarmonyOS NEXT的智慧农业物联网控制系统。 简单来说就是：两块开发板负责感知和控制环境参数，通过 MQTT 协议跟手机 App 实时通信， 最终实现温室里温度、湿度、光照、土壤水分的自动监测与智能调控。
嵌入式端
OpenHarmony + Hi3861 × 2
传感器采集 & 执行器控制
服务端
EMQX MQTT Broker
消息中转 & Topic 路由分发
应用端
HarmonyOS NEXT (API23)
Mate 70 Pro+ / MatePad Pro
01 · 项目总览与技术栈
整体架构、踩过的坑、做了哪些创新
系统架构：软硬协同、垂直整合
嵌入式端采集数据 → 服务端中转消息 → 手机端显示与控制
嵌入式端
OpenHarmony 1.0 Release
Rayawa/rgb @ HiSilicon-Hi3861
Rayawa/soi @ HiSilicon-Hi3861
传感器采集 + OLED 显示
PWM/GPIO 执行控制
服务端
MQTT 5.0 WebSocket
wss://broker.emqx.io:8084
@MQTTX
公网消息中转
Topic 路由分发
应用端
HarmonyOS 6.1.0 (API23)
Smart Shed @ Mate 70 Pro+
Smart Shed @ MatePad Pro 12.2
实时数据显示
手动 / 智能双模式
技术难点
开发过程中实际遇到的问题
嵌入式端
- 驱动接口版本兼容问题多
- I2C 总线多设备并发访问会冲突
- LiteOS-M 线程栈空间和优先级需要反复调
应用端
- 原文档基于 API7 的 JavaUI，太老了
- 原代码只能在特定平板上跑，换设备界面就乱
- 原来一个扩展板只能跑一个元件却设计了四套体系，重构量很大
通信层
- MQTT 传输不太稳定，报错信息也不明显
- Hi3861 WiFi 模块老化了，负载能力差
- 应用侧收发机制写得简陋，几乎没有错误处理，调试全靠猜
创新点
双板分离架构
环境感知板（RGB）和土壤执行板（SOI）物理隔离、逻辑解耦，各管各的又互相配合。
零依赖 MQTT 客户端
HarmonyOS 端完全从 TCP Socket 开始手搓 MQTT 报文，不依赖任何第三方库。
HDS 高级视觉体系
集成鸿蒙官方 Design System 组件库：沉浸式导航、引力动效、光场背景。
手动 / 智能双模式
手动模式自由调档位；智能模式根据阈值自动决策，后台线程安全常驻运行。
Glass 形态适配
额外做了手表端的 Glass 应用形态，沉浸式材质加气态动效。
可靠性保障
离线自动检测（5s 超时）、断线指数退避重连、GlobalLogBus 日志总线全方位兜底。
技术栈
嵌入式 (Hi3861)
服务端 (通信)
应用端 (HarmonyOS)
02 · MQTT 服务端
发布/订阅架构原理与数据流设计
发布/订阅（Pub/Sub）架构
MQTT 是一种轻量级的消息协议，专门为物联网低带宽场景设计的
三方协作机制
Publisher 发布者
嵌入式端 Hi3861 作为发布者，把传感器数据打包成 JSON 发到指定 Topic。
Broker 中转站
EMQX 充当 MQTT Broker，接收消息后按 Topic 规则转发给对应的订阅者。
Subscriber 订阅者
HarmonyOS App 订阅相关 Topic 后就能收到传感器数据，同时也能下发控制指令。
数据流设计
数据怎么从硬件一路跑到手机上，以及操作怎么传回硬件执行
上行：传感器数据 → 手机显示
① 传感器采样
扩展板上的传感器采集原始数据 → ADC 读光照/土壤湿度，I2C 读 AHT20 温湿度
② 打包发送
Hi3861 把数据转成 JSON 格式，通过 MQTT PUBLISH 报文发给 EMQX Broker
③ 路由分发
EMQX 收到消息后按 Topic 规则分发给已订阅的客户端
④ 刷新界面
HarmonyOS 接收并解析消息 → @StorageLink 更新状态 → UI 数字刷新 / 智能模式判断阈值
下行：用户操作 → 硬件执行
① 用户操作或自动触发
手动模式拖滑块调档位，或者智能模式下阈值越界自动生成控制指令
② 打包下发
HarmonyOS 把控制指令转成 MQTT 报文，经 EMQX 分发出去
③ 硬件执行
Hi3861 收到消息后解析主题和内容 → 控制 GPIO/PWM 输出 → 风扇/水泵/补光灯动作
03 · Hi3861 嵌入式端
OpenHarmony LiteOS-M + CMSIS-RTOS 多线程，纯 C 语言开发
两块开发板各司其职
RGB 板（环境感知）
负责"看环境"和"本地显示"
传感器
- AHT20 温湿度传感器 — I2C 读取温度与湿度
- 光敏电阻 — ADC 读取光照强度 (0~4095)
执行器
- RGB 三色灯 — GPIO10/11/12 => PWM1/2/3 控制亮度
本地显示
SSD1306 OLED (128×64) 实时刷新温湿度和光照数据
SOI 板（土壤执行）
负责"测土壤"和"干活"
传感器
- 土壤湿度传感器（替换安装）— ADC 读取土壤水分
执行器
- OLED 显示屏 — 本地状态打印
- 风扇 — PWM 控制转速
- 水泵 — GPIO 控制开关
项目结构
大分功能、小分模块，清晰好维护
common/ 公共层
Wi-Fi 连接、MQTT 通信、OLED 驱动都放这里。I2C 互斥锁也在这里管理，防止多线程抢总线。
modules/ 业务层
分两个子目录：
- sensors/ — AHT20、光强、土壤湿度传感器的头文件和程序
- actuators/ — 风扇、补光灯、水泵的控制程序
boards/ 构建层
两个开发板的 .gn 构建文件统一管理。条件编译按板卡动态启用模块，加新板子只需加个 gn 文件。
多线程架构
CMSIS-RTOS 管理 LiteOS-M 实时内核下的并行任务
主线程入口
- 系统启动后由 SYS_RUN 创建主线程
smart_shed_all.c，栈大小 8KB - 主线程依次初始化并拉起所有子线程：传感器采集、执行器控制、MQTT 通信、OLED 显示
- 条件编译按板卡配置动态启用对应模块，统一的调度入口
六个子线程并行工作
每个功能模块独立运行在 LiteOS 内核中，各自有栈空间（4KB~8KB）和优先级，互不阻塞：
空气温湿度采集
AHT20 / I2C
光照检测
ADC 采样
土壤湿度读取
ADC 采样
风扇/LED/水泵
GPIO/PWM 控制
OLED 显示刷新
SSD1306 渲染
MQTT 网络通信
Paho 发布/订阅
I2C 互斥锁：解决总线冲突
AHT20 温湿度传感器和 OLED 显示屏共用 I2C0 总线（GPIO13 & GPIO14），两个线程同时访问就会出问题。解决办法：
冲突场景
温湿度采集线程和 OLED 刷新线程同时读写 I2C0，导致数据错乱
解决方案
用 i2c0_lock/unlock 互斥锁，每次读写前后加锁解锁，保证同一时刻只有一个设备占用总线
硬件连接映射
SOI 板（土壤执行）
OLED
状态打印
I2C0-0x78 GPIO13&14
oled_ssd1306.c
土壤湿度
外接探头
ADC_CH4
soil_moisture_task.c
水泵
外接水泵
P06
water_pump_task.c
风扇
外接风扇
P08
fan_task.c
RGB 板（环境感知）
OLED
状态打印
I2C0-0x78 GPIO13&14
oled_ssd1306.c
温湿度传感器
检测空气参数
I2C0-0x44
temp_and_hum_task.c
光敏电阻
检测光照强度
ADC_CH4
light_intensity_task.c
三色灯 RGB
大棚光照控制
GPIO10/11/12=>PWM1/2/3
led_task.c
网络与通信
Wi-Fi 连上 → TCP 通了 → MQTT 收发 → 执行器动起来
通信流程
连 Wi-Fi
连接 SSID "Rayawa"，DHCP 拿到 IP 后进入 lwIP TCP 通信
MQTT 编解码
Paho 库只管报文的编解码，TCP Socket 的完整生命周期得自己管理
上报传感器数据
传感器数据以 JSON 格式上报到 EMQX Broker
执行控制指令
收到 PUBLISH 报文后用 MQTTDeserialize_publish() 解析主题和负载，再通过 mqtt_apply_command() 设置全局变量。执行器线程持续读这些变量来控制 GPIO/PWM，驱动风扇、水泵等设备工作
04 · HarmonyOS 应用端
ArkTS · Stage 模型 · HDS 高级视觉 · 自实现 MQTT 客户端
Smart Shed App
跑在 Mate 70 Pro+ 和 MatePad Pro 上的全功能控制终端
功能一览
手动模式
拖滑块调风扇(0-3档)、水泵(0-3档)、补光灯(0-100%)。进页面自动同步当前档位到开发板，支持触觉反馈。
智能模式
设定温度/湿度/光照/土壤湿度的上下限阈值。定时轮询传感器数据，超范围就自动触发控制。后台常驻线程，退出页面安全销毁防泄漏。
实时监控
MQTT 回调收传感器数据，@StorageLink 状态管理驱动 ArkUI 自动刷新数字显示。
调试面板
GlobalLogBus 事件总线记录通信状态、用户操作和错误信息，方便排查问题。
App 项目结构（Stage 模型）
基于 ArkTS 的分层架构
AppScope/
应用级全局资源和 Hvigor 构建脚本的统一管理入口。
view/ & pages/
ArkTS 构建的 UI 层，包含手动/智能双模式和调试面板的完整界面。
service/
封装 MQTT 客户端（MqttReceiverClient.ts），TCP Socket 直连实现双向通信，零第三方依赖。
viewmodel/
核心数据结构和状态模型，确保 UI 与数据的响应式绑定。
MqttReceiverClient.ts — 从零手写 MQTT 客户端
为什么自己写？
HarmonyOS 端没用任何第三方 MQTT 库，完全从 TCP Socket 开始手搓报文。这样对整个通信过程有完整的掌控力，出问题了也好排查。
协议层
- 手动拼接 Fixed Header + Variable Header + Payload
- 实现了 CONNECT / PUBLISH / SUBSCRIBE / PINGREQ 等核心报文
- 60s KeepAlive 心跳保活
- MQTT 5.0 over WSS 直连 EMQX 公网 Broker
可靠性保障
- 断线自动重连 + 指数退避
- 单 TCP 连接多 Topic 订阅与路由分发
- @StorageLink 状态管理与 ArkUI 解耦
- GlobalLogBus 日志总线记录完整通信轨迹
状态与方法
控制状态
集中管理风扇档位、水泵档位、补光灯亮度，@StorageLink 跨页面共享状态。
参数传递
传感器数据和控制指令通过统一格式在 MQTT 层可靠传输。
日志同步
GlobalLogBus 统一收集通信状态、操作记录和异常信息。
生命周期
进页面建连接、退页面销毁线程释放资源，杜绝内存泄漏。
UI 设计：HDS + ArkUI
兼顾功能与视觉体验
HDS 核心组件
HdsNav 导航栏
沉浸式光场顶部导航，毛玻璃模糊效果
PressShadow 引力动效
按钮按压弹性形变 + 光场扩散反馈
SpringMotion 弹簧动画
分步延迟进入，弹簧曲线入场体验流畅
视觉风格
深色光场
流光背景贯穿全界面，深色模式下氛围感拉满
双栏布局
平板自适应双栏，信息密度和视觉平衡兼顾
动效：引力场
页面切换时的引力场效果，元素间自然的吸引排斥动画。
动效：光场
流光背景+双栏深色全局光场，动态光影随交互流动变化。
动效：转场
淡入淡出+弹性动画，SpringMotion 弹簧曲线丝滑过渡。
响应式布局
ArkUI 响应式栅格系统，自动适配手机和平板两种设备形态：
手机端
单栏纵向滚动，卡片堆叠展示
平板端
双栏并列，充分利用宽屏空间
Smart Shed Glass
智能手表形态 —— 沉浸式材质 + 气态动效
Glass 形态特性
- 沉浸式材质 — 界面融入表盘玻璃质感
- 气态动效 — 轻盈飘逸的过渡动画
- 引力转场 — 保持和主 App 一致的交互语言
- 双边缘流光 — 表盘两侧动态装饰
HdsButtons 自定义组件
基于 HDS 规范自定义的按钮组件体系，统一 Glass 形态下所有交互元素的视觉表现和触摸反馈。支持多种尺寸和状态样式（默认/按压/禁用），小屏幕上也好用。
05 · 常见问题与总结
你可能会问的，以及这个项目带给我什么
常见问题
为什么选 OpenHarmony，而不是 Arduino / ESP32？
OpenHarmony 提供真正的 RTOS（LiteOS-M），有抢占式调度、原生多线程管理和成熟的华为硬件生态。Arduino / ESP32 适合做原型；而这个项目的重点是多任务、互斥锁、可配置栈和条件编译。何况，跟一个完整的操作系统打交道，和用一套框架做原型，是完全不同的学习体验。
开发一共用了多长时间？
总共约 6 周：2 周做嵌入式部分（驱动、多线程、MQTT），3 周做 HarmonyOS 应用（从 JavaUI API7 完整重写到 ArkTS API23、从零实现 MQTT 客户端、HDS 设计），1 周做联调、测试与报告。最耗时的是应用侧重写 —— 旧代码的迁移确实麻烦。
最大的技术挑战是什么？
毫无疑问是 I2C 总线冲突。AHT20 和 SSD1306 共用同一条 I2C0，采集线程和显示线程同时访问时就会乱套。解法看起来很简单（加个互斥锁），但定位问题花了我将近两天，最后靠逻辑分析仪才找到。其次是用 ArkTS 从零写一个完整的 MQTT 客户端，尤其是断线重连和线程生命周期的处理。
用了哪些调试工具？
嵌入式侧：USB 逻辑分析仪抓 I2C 总线、UART0 串口打印日志、MQTTX 实时观察消息。HarmonyOS 侧：DevEco Studio 自带调试器、HiLog 看系统日志，以及应用内置的 GlobalLogBus 面板实时跟踪 MQTT 活动。最有用的大概是 MQTTX —— 能实时看到 broker 上到底跑了什么，省了我不少个晚上。
这个项目能真正落地吗？
作为课程原型它已经比较完整。但要真正部署还缺几样：MQTT 认证（目前没有密码）、智能模式阈值的持久化（现在存在易失内存里）、以及初始配置界面（WiFi 的 SSID 和密码目前写死）。硬件方面，Hi3861 没有工业级认证，低成本传感器也缺标定。不过软件架构是扎实的，这些改进接进来不算难。
这个项目让你学到了什么？
比预想的多得多。技术上有：嵌入式系统编程、RTOS、物联网协议、现代移动应用开发。方法上有：怎么端到端设计一个分布式系统、怎么用清晰的分层控制复杂度、怎么把文档写好。而最重要的是：面对解释不了的硬件 bug 时的耐心，以及看着整套系统从传感器一路跑到手机屏幕时的成就感。
项目总结
一个从零到一的项目
从第一行代码到最终答辩，SmartShed 是一次穿越 HarmonyOS / OpenHarmony 生态的完整旅程。我几乎碰到了 IoT 系统的每一层：硬件驱动、RTOS、网络协议、移动应用开发、界面设计，甚至还有一点构建链（GN / Ninja）的工程工作。
如果只让我记一件事，那就是复杂度要靠架构来管理。一开始我试图把所有东西塞进一个文件 —— 结果是维护噩梦。重构成分层结构（common / modules / boards）并在应用侧采用 Stage 模型之后，每一次修改都变得有针对性、可预期。
谢谢你读到这里。如果这个项目给了你启发，或者你有问题，欢迎联系我，也可以去 GitHub 上看源码 —— 它完全开源。