系统架构

系统分为四层：设备端、MQTT 消息层、平台端和前端。设备负责采样和执行，EMQX 负责转发，history_service 负责存储和接口，uni-app 前端负责显示和控制。

架构图

数据流

1. STM32 采集 DHT11、MQ135 等传感器数据。
2. STM32 通过 ESP8266 接入局域网，并使用 MQTT 与 EMQX 通信。
3. 设备将实时遥测发布到 device/stm32f103/up。
4. history_service 订阅上行主题，解析消息并写入 PostgreSQL。
5. 前端通过 HTTP 调用 /api/latest、/api/history 等接口读取数据。
6. 当前端发起台灯、告警阈值或风扇配置操作时，请求会先到后端，再由后端向 device/stm32f103/down 发布控制消息。

分层职责

设备端 OLED 会显示温度、湿度和空气质量等实时数据。

STM32 主板与扩展模块接线示意，ESP8266 负责 WiFi 接入与 MQTT 通信。

STM32 + ESP8266

• 采样 DHT11、MQ135 等传感器数据。
• 执行本地控制并驱动 OLED 显示。
• 通过 AT 指令驱动 ESP8266。
• 发布 MQTT 遥测并接收下行控制。

EMQX

• 负责设备与后端之间的 MQTT 消息转发。
• 上行主题：device/stm32f103/up
• 下行主题：device/stm32f103/down

history_service

• 订阅设备上报。
• 存储历史记录。
• 对前端暴露 HTTP API。
• 接收前端控制请求后转发为 MQTT 下行消息。

前端

• 显示实时状态与历史曲线。
• 配置告警阈值。
• 控制台灯和风扇。
• 展示天气与空气质量卡片。

告警与空气质量

MQ135 的 AO 和 DO 在系统中承担不同职责，需要和主告警状态分开理解。

1. gasPpm 来自 MQ135 的 AO 模拟量换算值，表示软件估算的 ppm。
2. gas 来自 MQ135 的 DO 比较器状态，表示硬件比较器是否触发。
3. alarm 主告警状态，由温度、湿度和 gasPpm 的软件阈值共同决定。

当前规则：

1. DO 不再直接触发主告警。
2. gasCalibrated=false 时前端显示“预热中”。
3. 前端将“硬件比较器状态”和“ppm 等级”分开显示。