★ FEATURED ARTICLE 简介面向本科毕设与物联网开发的智能家居完整项目包围绕CC2530控制器、ZigBee协议栈、ESP-01s网关、腾讯云服务器、MySQL数据库及Android客户端给出从硬件采集到远程控制的闭环方案。全套共1414个文件含c与h格式的嵌入式节点源码、java与xml格式的Android与SpringMVC服务端代码、工程配置文件、jpg/png格式的电路与界面图示、pdf说明文档以及相关嵌入式工程文件压缩包102.12MB。系统支持实时查看温湿度、烟雾浓度和光照强度远程操作风扇、电灯与蜂鸣器并可统计导出Excel异常时自动蜂鸣报警并邮件通知适合需要参考完整业务流与软硬件联调细节的读者也适合作为课程设计与项目实训素材。方案覆盖传感器驱动、网关联网、数据库设计、Socket通信和移动端UI附有项目详细说明和软硬件资料可支撑毕业设计演示、论文撰写与二次开发。目前已有874人学习下载覆盖物联网、嵌入式与Android方向的学习人群。1. 基于ZigBee的智能家居毕设先把方案看懂再决定要不要照着重做做智能家居类毕设最容易翻车的不是硬件焊不好而是软件链路太长传感器数据采集、ZigBee组网、网关转发、云端存储、APP显示五个环节只要有一个是黑匣子整个系统就跑不通。这套基于ZigBee的智能家居项目正好把这条链路完整打通了——CC2530采集端负责获取温湿度、烟雾浓度和光照强度ESP-01s网关把串口数据转成TCP协议送上云服务器服务端用SpringMVC接收存储Android APP负责实时显示和远程控制。适合正在做物联网方向毕设、又不想从零开始啃协议栈的同学参考也适合想了解真实智能家居系统分层的从业者当案例拆解。资源里除了源码还带了协议栈配置文件、硬件资料和项目说明复现路径相对完整。2. ZigBee组网与CC2530采集端协议栈配置、终端节点编写与传感器驱动2.1 ZigBee协议栈选型为什么用Z-Stack而不是自己写协议ZigBee的协议栈非常复杂从物理层到应用层涉及信道管理、路由协议、绑定机制等如果从零实现半年时间都不够。这套项目选择了TI的Z-Stack协议栈它跑在CC2530上把底层网络通信封装好了开发者只需要关注应用层的逻辑。实际上这也是绝大多数ZigBee毕设的常规做法没必要自己造轮子。常见的做法是下载TI官方的Z-Stack协议栈安装包然后基于SampleApp或SampleSwitch工程修改。协议栈安装完成后在安装目录的Projects文件夹下能看到多个示例工程其中SampleApp演示了无线收发数据的基本流程SampleSwitch演示了开关控制类设备的行为。此项目的源码包里保留了SampleApp.cspy.bat和SampleSwitch.cspy.bat这两个调试脚本说明作者是基于这两个示例工程做的二次开发。我一般会建议先把这两个示例工程分别编译一遍烧录到两块CC2530模块里观察它们能不能互相通信。这个过程可以验证开发环境是否正常、仿真器驱动是否装好也可以确认无线通信的默认信道和PAN ID是否一致。2.2 IAR工程结构从cspy调试脚本看到的关键配置这个项目源码里出现了gradlew.bat这是Android项目的Gradle构建脚本而SampleApp.cspy.bat和SampleSwitch.cspy.bat是IAR Embedded Workbench的调试命令行脚本。cspy脚本的典型作用是调用仿真器驱动把编译好的固件下载到CC2530芯片里。C:\Program Files\IAR Systems\Embedded Workbench 8.1\common\bin\cspy.bat 这条命令会被cspy.bat脚本内部调用它实际做的事情是加载调试驱动、连接仿真器、烧录固件。需要注意不同的Z-Stack版本对应的IAR版本不同Z-Stack 2.5.1a通常配IAR 8.10如果版本不匹配编译时会报一堆莫名其妙的错误这是第一个隐藏坑。编译CC2530工程的步骤一般是这样# 打开IAR Embedded Workbench # File - Open Workspace - 选择 Z-Stack 安装目录下 # Projects\zstack\Samples\SampleApp\CC2530DB\SampleApp.eww # 然后在Workspace窗口将工程配置切换为 CC2530DB # 右键工程名 - Rebuild All编译成功后在工程目录的Debug\Exe文件夹下会生成SampleApp.hex文件。这个hex文件就是最终要烧录到CC2530里的固件。烧录方式有两种一种是直接用IAR的Download and Debug按钮一种是使用TI的SmartRF Flash Programmer工具烧写hex文件。第二种更适合批量烧录多个节点模块。如果编译时报错找不到某个头文件大概率是工程的头文件路径没有匹配当前协议栈的安装位置。IAR工程选项里的Preprocessor选项卡需要把协议栈相关头文件的绝对路径改成你本机的实际路径。2.3 终端节点逻辑传感器采集与周期上报的实现思路终端节点是整个系统的数据来源。资源里提到的传感器包括温湿度、烟雾浓度和光照强度这三类它们在CC2530上的接入方式大同小异基本都是ADC采样或数字接口通信。以光照强度采集为例常见做法是使用光敏电阻配合ADC通道采集电压值再通过电压与光照强度的线性关系换算成实际光照读数。温湿度传感器常用DHT11这类数字传感器单总线协议读取即可。烟雾浓度检测则一般用MQ-2烟雾传感器其输出是模拟电压同样走ADC通道。终端节点的核心逻辑在Z-Stack应用层里编程模型大致如下// 应用层任务初始化函数 void SampleApp_Init( uint8 task_id ) { // 初始化ADC通道用于读取光敏电阻或烟雾传感器电压 P0SEL | 0x03; // 配置P0.0和P0.1为外设功能 ADCIF 0; // 清除ADC中断标志 ADCCON3 0x30; // 配置ADC参考电压为AVDD516位分辨率 // 初始化定时器设置采样周期例如每5秒上报一次 osal_start_timerEx( task_id, SAMPLEAPP_SEND_PERIODIC_EVT, 5000 ); } // 事件处理函数 uint16 SampleApp_ProcessEvent( uint8 task_id, uint16 events ) { if ( events SAMPLEAPP_SEND_PERIODIC_EVT ) { // 读取传感器数据 uint16 light_value read_light_sensor(); uint16 smoke_value read_smoke_sensor(); // 将传感器数据打包成ZigBee数据帧 // 目的地址设为协调器的短地址0x0000 // 数据内容按自定义协议填充 // 调用AF_DataRequest()发送数据到协调器 AF_DataRequest( SampleApp_DstAddr, SampleApp_epDesc, SAMPLEAPP_PERIODIC_CLUSTERID, data_len, data_buf, SampleApp_TransID, AF_DISCV_ROUTE, AF_DEFAULT_RADIUS ); // 重新启动定时器进入下一个采样周期 osal_start_timerEx( task_id, SAMPLEAPP_SEND_PERIODIC_EVT, sendPeriodicTimeout ); } }这段代码需要关注的点有三个第一ADC通道配置里ADCCON3寄存器的参考电压选择和分辨率会影响采集精度。如果项目里对光照强度精度要求不高用默认配置就够了但如果数值明显异常优先检查参考电压是不是稳定的3.3V。第二AF_DataRequest函数的第一个参数决定数据发给谁。终端节点必须把数据发给协调器因为协调器负责把数据汇总后通过串口转发给网关。目的地址设为0x0000表示协调器的短地址。第三采样周期的设置要根据实际场景调整。如果周期太短ZigBee网络会频繁唤醒功耗偏高如果周期太长APP端的实时性又会很差。我一般设置5到10秒上报一次兼顾功耗和实时性。3. 协调器与网关改造ESP-01s如何把串口数据送进互联网3.1 协调器节点模式为什么它是整个ZigBee网络的中枢协调器是ZigBee网络的创建者负责建立网络、分配短地址、维护路由表。它本身不参与具体的数据处理但所有终端节点的数据都会汇集到它这里。协调器通过串口与网关模块通信把接收到的ZigBee数据帧解析成原始的传感器数值再通过串口发送给ESP-01s。在Z-Stack工程里协调器的角色由编译选项控制。SampleApp工程中协调器和终端节点共用一套代码区别在于编译时是否定义ZDO_COORDINATOR宏// 在IAR工程的Preprocessor选项里 // 协调器定义ZDO_COORDINATORTRUE // 终端节点不定义此宏或者设置为FALSE这里的关键操作是串口初始化。协调器需要通过串口把数据发出去串口波特率必须和ESP-01s的AT模式波特率一致通常设为9600或115200。配置串口时要注意引脚映射CC2530的USART模块可以映射到不同的P0口组合如果映射错误串口收到的数据会是一堆乱码。3.2 ESP-01s网关透传AT指令集配置与UDP/TCP模式选择ESP-01s是ESP8266系列里引脚最少、成本最低的一颗WiFi模块此项目里用它做网关是最省事的方案。它的工作模式分为透传模式和普通模式透传模式下串口收到的所有数据都会直接转发到远端服务器。网关的核心逻辑是CC2530通过串口发数据给ESP-01sESP-01s通过WiFi把数据发到服务器端。反过来服务器下发控制指令时ESP-01s通过串口把指令传给CC2530CC2530再通过ZigBee网络转发给对应的终端节点。ESP-01s的AT指令配置可以参考以下流程# 1. 设置WiFi模块工作模式为Station ATCWMODE1 # 2. 连接家庭路由器 ATCWJAP你的WiFi名称,你的WiFi密码 # 3. 启用TCP传输模式 ATCIPMODE1 # 4. 建立TCP连接指向服务器的IP和端口 ATCIPSTARTTCP,192.168.1.100,8080 # 5. 进入透传模式 ATCIPSEND执行完这些指令后ESP-01s会进入透传状态此时CC2530发给它的任何串口数据都会原样转发到服务器。这里要注意AT指令的返回判断每条指令发出后都要检查是否返回了OK或SEND OK如果连接不成功需要先检查WiFi密码是否正确、服务器端口是否可用。网关透传模式有一个坑ESP-01s一旦进入透传模式就无法直接接收AT指令了必须先发送才能退出透传。这意味着调试时要特别注意顺序如果先进入透传再想去改服务器地址会卡住。3.3 数据帧格式设计传感器标识、数值编码与校验位ZigBee网络传来的原始数据是一串字节流网关或服务器需要能解析出这是哪个终端节点发来的数据、属于哪种传感器类型、数值是多少。资源里提供了一个自定义的数据帧协议固定格式大致如下帧头(0xAA) 节点地址(1字节) 设备类型(1字节) 数据值(2字节) 帧尾(0x55)例如1号终端节点的温度传感器上报26.5度编码成字节流就是0xAA 0x01 0x01 0x00 0xD9 0x550xAA帧头0x01终端节点地址0x01设备类型1表示温度传感器0x00 0xD9温度值0x00D9等于217表示21.7度保留一位小数0x55帧尾这个自定义协议的好处是解析简单、容错性好。服务器端收到一帧数据后先检查帧头和帧尾是否匹配再检查数据长度是否符合预期最后根据设备类型字段分发到不同的存储逻辑。我建议在这个格式基础上增加一个校验字段比如CRC8校验或累加和校验。因为WiFi传输过程中偶尔会出现丢字节或乱序的情况没有校验位时服务器可能把一帧错误数据当成真实数据写入数据库导致APP显示异常。4. 云端服务与Android APP联动SpringMVC、MySQL、Socket和消息推送4.1 服务端架构Socket接收数据与HTTP接口分工整个系统的服务端承担两个任务一是和ESP-01s保持长连接持续接收设备上报的数据二是为Android APP提供HTTP接口让APP能查询实时数据和下发控制指令。这两个任务在技术选型上是分开的。Socket部分用于接收ESP-01s推送的数据。网关侧建立的是TCP客户端连接服务端需要开启一个TCP服务端口持续监听网关连接。数据到达后服务端解析数据帧把传感器数值写入MySQL数据库。HTTP部分使用SpringMVC框架提供RESTful接口给Android APP调用接口路径大致如下GET /api/sensor/latest // 查询最新一条传感器数据 GET /api/sensor/history // 查询历史数据支持按时间段过滤 POST /api/device/control // 下发控制指令控制风扇、电灯、蜂鸣器 GET /api/statistics/export // 导出统计数据生成Excel服务端接收到HTTP请求后从数据库查询数据并组装成JSON返回给APP。这里要注意的是Socket端口和HTTP端口不能冲突一般Socket用8080HTTP用8081或者Socket用9000HTTP用8080。4.2 SpringMVC控制器核心代码结构与请求处理流程SpringMVC控制器是服务端的主要入口处理HTTP请求、执行业务逻辑、返回JSON数据。此项目的控制器结构大致如下RestController RequestMapping(/api) public class DeviceController { Autowired private SensorDataService sensorDataService; Autowired private DeviceControlService deviceControlService; // 获取最新传感器数据 GetMapping(/sensor/latest) public MapString, Object getLatestSensorData() { MapString, Object result new HashMap(); SensorData data sensorDataService.getLatestData(); result.put(temperature, data.getTemperature()); result.put(humidity, data.getHumidity()); result.put(smoke, data.getSmoke()); result.put(light, data.getLight()); result.put(updateTime, data.getCreateTime()); return result; } // 下发设备控制指令 PostMapping(/device/control) public MapString, Object controlDevice(RequestBody ControlRequest request) { // request中包含设备编号和控制动作 // 通过Socket通道发送控制指令到ESP-01s网关 boolean success deviceControlService.sendCommand(request); MapString, Object result new HashMap(); result.put(success, success); result.put(message, success ? 指令已下发 : 指令下发失败); return result; } }这段代码有两个动作比较关键查询最新数据以及下发控制指令。查询最新数据只依赖数据库难度不大下发控制指令需要服务端把指令通过Socket发送给网关而网关和服务器之间是长连接服务端必须维护一个Socket会话池记录当前哪些网关是在线的这样才能准确地把指令推送到对应的网关。实际开发时我都会在服务端维护一个Mapkey是网关的设备编号value是Socket通道对象。设备控制请求进来时先从Map里找到对应的Socket通道再通过该通道把指令发给ESP-01sESP-01s串口转给协调器协调器再通过ZigBee网络找到目标终端节点。4.3 MySQL表结构设计传感器数据表、控制日志表与统计查询数据库设计的合理性直接影响查询效率和统计功能的实现难度。此项目的MySQL数据库中至少应该包含两张核心表传感器数据表和设备控制日志表。传感器数据表的DDL如下CREATE TABLE sensor_data ( id INT AUTO_INCREMENT PRIMARY KEY, node_address VARCHAR(8) COMMENT 终端节点地址, device_id INT COMMENT 设备类型1温度 2湿度 3烟雾 4光照, sensor_value DECIMAL(8,2) COMMENT 传感器数值, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 数据采集时间 ) COMMENT 传感器采集数据表;设备控制日志表记录用户每次对电灯、风扇、蜂鸣器的操作CREATE TABLE device_log ( id INT AUTO_INCREMENT PRIMARY KEY, device_name VARCHAR(32) COMMENT 设备名称, action VARCHAR(8) COMMENT 开或关, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 操作时间 ) COMMENT 设备控制日志表;在设计这张表结构时需要注意节点地址和传感器数值这两个字段的类型选择。节点地址是短地址实际上是一个两位十六进制数用VARCHAR类型存储没问题。传感器数值用DECIMAL保留两位小数避免浮点误差。统计查询这块Excel导出功能依赖SQL进行数据聚合。最常见的做法是把一天内的数据按小时分组统计平均值SELECT HOUR(create_time) AS hour, AVG(CASE WHEN device_id 1 THEN sensor_value END) AS avg_temp, AVG(CASE WHEN device_id 2 THEN sensor_value END) AS avg_humi FROM sensor_data WHERE create_time 2025-01-01 00:00:00 AND create_time 2025-01-01 23:59:59 GROUP BY HOUR(create_time) ORDER BY hour;这条SQL使用CASE WHEN配合AVG函数在同一个查询里完成多类型传感器数据的按小时聚合一次性查出一天的温度和湿度平均值相比多次查询再合并的方式效率高很多。4.4 Android APP端数据请求、状态刷新与控制指令发送Android APP部分的核心功能是循环请求服务端接口获取最新数据、把传感器数值显示在UI上、监听用户操作并发送控制指令。整个APP的网络层使用OkHttp框架JSON解析使用Gson或Fastjson。拿到资源里的Android项目后需要重点修改的是服务端IP地址配置。开发调试时服务端可能运行在局域网内的某台电脑上APP中的服务器地址会设置为一串局域网IP例如http://192.168.1.100:8080。如果需要部署到公网则要替换为公网服务器地址。APP端请求最新传感器数据的代码逻辑如下// MainActivity.java 中 private void refreshSensorData() { // 构建HTTP请求 Request request new Request.Builder() .url(baseUrl /api/sensor/latest) .get() .build(); // 使用OkHttp发起异步请求 OkHttpClient client new OkHttpClient(); client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { // 网络请求失败更新UI为未连接状态 runOnUiThread(() - statusTextView.setText(连接失败)); } Override public void onResponse(Call call, Response response) throws IOException { // 解析JSON数据 String body response.body().string(); JSONObject json new JSONObject(body); float temperature (float) json.getDouble(temperature); // 更新UI显示 runOnUiThread(() - { tempTextView.setText(String.format(%.1f℃, temperature)); // 判断异常状态触发报警提示 if (temperature thresholdTemp) { alarmTextView.setVisibility(View.VISIBLE); } }); } }); }这段代码的状态刷新方式是轮询。使用Handler或定时器每隔几秒调用一次refreshSensorData()方法即可实现APP端数据的近似实时刷新。轮询间隔建议设为5秒太短会导致服务端请求压力过大太长会让人觉得数据不够即时。发送控制指令的代码逻辑类似区别在于POST请求需要携带参数// 控制电灯开关 private void controlLight(boolean on) { JSONObject body new JSONObject(); try { body.put(device, light); body.put(action, on ? on : off); } catch (JSONException e) { e.printStackTrace(); } Request request new Request.Builder() .url(baseUrl /api/device/control) .post(RequestBody.create( MediaType.parse(application/json), body.toString())) .build(); }APP端的坑主要集中在三个地方一是Android 9及以上版本默认禁止明文HTTP流量需要在AndroidManifest.xml中配置usesCleartextTraffic为true否则请求会直接失败二是网络请求不能放在主线程执行必须使用异步线程或协程三是实时刷新功能必须在onDestroy中取消定时器否则Activity销毁后还会继续请求造成内存泄漏。5. 避坑指南ZigBee智能家居项目从复现到跑通的常见问题5.1 仿真器连不上CC2530IAR报Failed to connect到目标设备现象使用CC Debugger仿真器连接CC2530开发板后IAR点击Download and Debug弹窗报Failed to connect to target程序无法烧录。原因最常见的有三种情况。一是仿真器的驱动没有安装或者安装的是不匹配的驱动版本二是CC2530开发板没有正确供电芯片处于未上电状态三是IAR工程中的调试器选择错误没有选到CC Debugger对应的调试器类型。解决先打开设备管理器确认仿真器能否被识别如果显示黄色感叹号需要重新安装驱动。然后在IAR工程中依次打开Project - Options - Debugger将Driver选择为Texas Instruments并在Texas Instruments选项页里将Interface改为2-wire JTAG。最后检查开发板的供电指示灯是否正常亮起。以上操作依次排查覆盖了驱动层面、配置层面和硬件层面。5.2 ZigBee节点互相收不到数据发送端和接收端都正常现象协调器和终端节点都烧录了固件终端节点的数据发送代码已经执行但协调器的串口监视器没有任何数据输出。原因ZigBee网络通信最核心的要求是PAN ID和信道一致。如果协调器在编译时配置了固定的PAN ID和默认信道而终端节点用的是另一份配置两者就不在同一个网络上数据自然传不过去。另外终端节点要按照入网流程操作有些情况下需要按一下按键触发入网否则它还在不断搜索网络。解决检查协调器和终端节点的工程配置在f8wConfig.cfg文件中确认DEFAULT_CHANLIST是否一致DEFAULT_PAN_ID是否配置为同一个值。终端节点如果配置了入网按键按住按键直到LED闪烁再松开等待它加入网络。入网成功后理论上数据就能正常传输了。5.3 ESP-01s透传模式下收不到服务器的控制指令现象传感器数据能正常从ESP-01s传送到服务器但服务器下发的控制指令始终无法到达CC2530APP端显示发送成功但设备不动作。原因透传模式是单向的。ESP-01s进入透传模式后数据从串口转发到远端服务器这条链路是通的但服务器往ESP-01s发数据时ESP-01s只会把收到的数据转发到串口。如果服务器的数据没有正确写入Socket通道或者写入后没有发送出去ESP-01s自然收不到。还有一个常见情况是网关的串口波特率不匹配。CC2530的串口波特率是9600ESP-01s的默认波特率也可能是9600但这两个波特率如果不一致数据就会变成乱码。解决先用串口调试助手分别验证两段链路。在CC2530的串口调试助手中手动发送一条指令观察ESP-01s是否能把指令转发到路由器再传送到服务器然后从服务器的Socket客户端手动发送一条指令观察ESP-01s是否已经把数据转发到CC2530的串口。哪一段断了重点排查哪一段的波特率和引脚连接。5.4 MySQL存储的传感器数值全是0或者固定不变现象APP端能显示传感器数据但数据永远是0或者同一个值不随环境变化。原因传感器采集的数据不变化基本都是传感器电路连接的问题。光敏电阻和烟雾传感器都是模拟输出如果传感器的电源没有接好ADC采到的电压就是恒定的0V如果传感器的AO引脚没有正确连接到CC2530的ADC引脚采到的就是悬空电压。解决先用万用表测量传感器的VCC引脚确认有3.3V电源。然后检查传感器的AO输出引脚是否接到了CC2530正确的ADC引脚原理图上标注的ADC通道是否与代码中配置的通道一致。如果使用的是DHT11这类数字传感器还要检查数据线是否接了上拉电阻没有上拉电阻的情况下DHT11无法正常通信。5.5 Android APP请求不到服务端数据日志显示ConnectException现象安装了APP之后点击刷新按钮界面一直停留在加载状态最终显示连接失败。原因Android设备访问不到服务端的IP地址。在局域网调试时最常见的原因是Android手机和电脑不在同一个局域网或者电脑的防火墙拦截了8080端口。连接公网服务器时可能是服务器安全组没有放通对应端口。解决先确认服务端能正常启动用电脑的浏览器访问http://服务端IP:8080/api/sensor/latest测试接口是否可访问。如果不行检查服务端防火墙设置在Windows防火墙的入站规则中放行8080和9000端口。如果电脑浏览器能访问而手机不行检查手机与电脑是否连接了同一个路由器。公网部署时检查云服务器的安全组规则TCP端口需要放通Socket端口和HTTP端口。5.6 邮箱报警功能发送失败报错信息是认证失败现象系统出现异常状态时蜂鸣器能正常响但邮件通知一直没有收到服务端日志显示AuthenticationFailedException。原因邮箱报警功能使用的是SMTP协议发送邮件服务端代码中配置的邮箱账号和授权码不对或者是使用了邮箱的登录密码而不是授权码。很多邮箱服务商默认不开放SMTP功能需要在邮箱设置中手动开启并生成专用授权码。解决登录邮箱的网页版设置中心找到SMTP服务选项开启服务并生成独立授权码。把服务端代码中的邮箱密码字段替换为授权码而不是登录密码。替换完成后重新触发一次异常报警观察服务端日志是否显示发送成功。6. 进阶验证多节点扩展、Excel导出压测与整链路自检习惯复现这套项目跑通基础功能之后建议再做三个方向的验证把系统从能用推到可靠。这三个方向分别对应硬件扩展能力、数据导出能力和整链路稳定性是真正能让答辩或交付时拿出实据的部分。多节点扩展验证最容易发现ZigBee组网能力的边界。先在协调器工程配置里查看MAX_DEVICES相关的宏定义然后逐步增加终端节点的数量。比如先跑三个终端节点分别挂温湿度、烟雾和光照传感器观察协调器串口输出的数据帧是否按节点地址区分清晰。再增加到五个节点此时需要重点观察在网络建立初期是否有节点连续入网失败的现象。我一般会在同一时间把所有节点同时上电然后看协调器的串口输出记录每个节点入网的耗时如果超过15秒还没有收到某节点的入网广播就得检查该节点的发射功率和天线焊接情况了。Excel导出功能建议做一次数据量压测。在MySQL中批量插入一万条模拟数据再调用导出接口观察接口从发起请求到文件生成完成的耗时以及生成的文件在Excel中是否能正确打开。这一步能暴露两个隐藏问题一是服务端内存溢出如果一次性把所有数据读入内存再写Excel数据量大时容易报OOM二是日期格式和值格式错乱温度显示成文本而不是数值。如果压测中发现耗时过长可以在SQL查询中加上分页或用流式查询优化。这个验证不一定要在答辩时展示但跑一次就能避免演示现场导出卡死的尴尬。整链路自检是我每次部署这套系统都会强制走一遍的流程。顺序是先看CC2530协调器串口是否有传感器数据输出再检查ESP-01s的WiFi指示灯是否常亮接着打开电脑浏览器直接访问服务端HTTP接口确认数据入库最后用手机APP刷新看数据是否显示一致。四步都通过链路才算健康。自从有一次在演示现场发现APP显示正常但服务端日志里全是Socket超时报错之后我每次调试都会把这一步当成习惯顺序核对链路温度、湿度、烟雾、光照四路数据从传感器到APP的全链路一致性。希望这套思路能帮你在复现这个项目时少走弯路也祝你的毕设答辩顺利。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
