企业官网建设流程全解析

1. 为什么我选择ESP32-C6加Zigbee这条路线

1.1 从一次室内空气检测的尴尬说起

去年冬天我在书房里连续加班了几天，总觉得下午开始头昏脑涨，一开始以为是睡眠不足，后来随手拿了一个便携式二氧化碳检测仪测了一下，读数直接飙到1800ppm以上。窗户一开，数值十分钟内掉到600ppm，人也立刻清醒了。这件事让我意识到，室内空气质量这件事，靠鼻子和感觉是完全靠不住的，必须有一个长期在线、能记录趋势、能自动联动通风设备的监测节点。

市面上的成品监测仪我前后用过三四款，问题集中在几个地方：便宜的传感器精度堪忧，贵的又封闭得厉害，数据只能在自己App里看，想接入自己的自动化系统基本没门。我家里本来就跑着一套Home Assistant做全屋自动化，灯光、窗帘、空调都在里面统一管理，所以我很自然地想：为什么不自己做一个空气质量监测仪，直接把它变成Home Assistant里的一个原生设备？

选型的时候我考虑过三条路。第一条是WiFi方案，用ESP32直接连MQTT，这条路我做过很多次，成熟稳定，但缺点是每个节点都要占一个IP、吃一份路由器的连接数，家里设备一多，路由器压力就上来了，而且WiFi的功耗对电池供电不友好。第二条是蓝牙方案，功耗低，但覆盖范围小，穿墙能力差，还得依赖一个常开的网关做转发。第三条就是Zigbee，低功耗、自组网、Mesh拓扑，一个协调器能带几十个节点，而且Home Assistant对Zigbee的支持已经非常成熟。

真正让我下定决心的，是ESP32-C6这颗芯片。它是乐鑫第一颗原生集成802.15.4射频的芯片，也就是说Zigbee和Thread的物理层直接做在片子里了，不需要外挂一个CC2530之类的独立射频模块。这一下就把BOM成本和PCB面积都压下来了，同时它还有RISC-V主核加一个低功耗协处理器，跑传感器采集和Zigbee协议栈绰绰有余。所以最终方案就定下来了：ESP32-C6做Zigbee终端设备，直连Home Assistant的Zigbee协调器。

1.2 这套方案到底解决了什么问题

先说清楚这个项目做出来是个什么东西。它是一个基于ESP32-C6的Zigbee终端节点，板子上挂载空气质量相关的传感器，采集到的数据通过Zigbee协议上报给Home Assistant的Zigbee协调器，在Home Assistant里表现为标准的传感器实体，可以直接用于仪表盘展示、历史记录、自动化触发。

它解决的问题可以拆成三层。第一层是数据主权问题，所有数据都在你自己的Home Assistant里，不经过任何第三方云，历史数据想存多久存多久，想怎么分析就怎么分析。第二层是联动问题，因为它是Home Assistant里的原生实体，你可以直接写自动化，比如CO2超过1000ppm就打开新风，PM2.5超标就启动净化器，温湿度偏离舒适区就调整空调，这些都是几行YAML的事。第三层是成本和可扩展性问题，一个节点的物料成本可以控制在几十块钱，而且Zigbee Mesh的特性意味着你每多加一个节点，网络的覆盖和稳定性反而更好。

适合谁来参考这篇内容？如果你已经有一套Home Assistant在跑，并且有Zigbee协调器，那这个项目对你来说是即插即用的。如果你还没有Home Assistant，但会一点嵌入式开发，那也可以把它当成一个学习Zigbee终端设备开发的练手项目。如果你完全是新手，我建议先花点时间把Home Assistant和Zigbee协调器跑起来，再回来看这个项目，会顺畅很多。

1.3 整体架构长什么样

在动手之前，先把整个数据链路在脑子里过一遍，这样后面每一步你都知道自己在干什么。

整个链路是这样的：传感器通过I2C或者UART把原始数据给到ESP32-C6，ESP32-C6上的固件把原始数据转换成有物理意义的数值，然后通过Zigbee协议栈把这些数值封装成Zigbee簇属性，通过无线发给Zigbee协调器，协调器再通过串口或者网络把数据交给Home Assistant的Zigbee集成，最后在Home Assistant里生成对应的传感器实体。

这里面有几个关键的角色需要区分清楚。Zigbee协调器是整个网络的中心，负责组建网络、分配地址、路由数据，它通常是一个USB棒插在跑Home Assistant的主机上。ESP32-C6在这里扮演的是Zigbee终端设备（End Device），它不负责路由，只负责采集和上报，这样可以最大化省电。中间可能还有Zigbee路由器（Router），通常是市电供电的设备，负责转发数据扩展覆盖，但在这个项目里我们不需要自己造路由器，家里其他市电供电的Zigbee设备会自动承担这个角色。

理解这个架构之后，你会发现这个项目的核心工作其实就两块：一是把传感器数据读对，二是把数据正确地映射成Zigbee标准簇属性。前者是硬件和驱动的事，后者是Zigbee应用层的事。下面我就按这个思路一步步展开。

2. 硬件选型与电路设计的关键考量

2.1 ESP32-C6模组怎么挑

ESP32-C6目前市面上能买到的模组主要有几个方向。一类是官方模组，比如ESP32-C6-WROOM系列，集成了芯片、Flash、晶振和天线匹配电路，射频性能有保证，认证也齐全，缺点是价格比裸片方案略高，而且天线形式固定。另一类是各种开发板，比如带USB转串口、带按键和LED的板子，适合快速验证，但做成品的话体积偏大。

我自己的做法是：验证阶段用开发板，快速把固件跑通；做成品的时候换成官方模组，自己画一块小板子。选模组的时候有几个参数必须确认。第一是Flash容量，Zigbee协议栈加上应用固件，4MB是起步，8MB会更从容，尤其是你后面想加OTA功能的话。第二是天线形式，PCB天线成本低但增益一般，IPEX外接天线灵活但多一个连接器成本，室内监测节点一般PCB天线就够了，除非你要放在金属箱体里。第三是工作温度范围，如果只是室内用，商业级就够了。

还有一个容易被忽略的点是模组的射频匹配。ESP32-C6的802.15.4射频工作在2.4GHz，和WiFi共用频段，所以天线匹配电路的设计直接影响通信距离和稳定性。如果你自己画板，一定要严格照着官方模组的参考设计来，尤其是匹配网络的电感和电容值，不要自己随便改。我见过有人为了省两个元件把匹配网络简化了，结果通信距离直接砍半。

2.2 空气质量传感器怎么选

这是整个项目里最影响最终效果的部分，值得多花点篇幅。空气质量是个很宽的概念，你到底要测什么，直接决定了选什么传感器。

最常见的几个指标是：温度、湿度、二氧化碳、PM2.5、TVOC（总挥发性有机物）、甲醛。温湿度基本是标配，用SHT系列或者AHT系列都行，I2C接口，精度够用，价格便宜。二氧化碳我强烈建议用NDIR（非色散红外）原理的传感器，比如SCD4x系列，它是真正通过红外吸收测CO2浓度，精度和长期稳定性都远好于那些所谓的eCO2（等效二氧化碳）传感器。eCO2本质上是靠TVOC推算出来的，你喷一下酒精它都能飙到2000ppm，参考价值有限。

PM2.5的话，激光散射原理的传感器是主流，比如PM1006、PMS5003这类，通过风扇把空气抽进光腔，颗粒物散射激光，接收管根据散射光强度推算浓度。这类传感器要注意的是风扇寿命和定期校准，用久了光腔积灰会导致读数偏高。TVOC可以用SGP系列或者CCS811这类金属氧化物传感器，但这类传感器需要预热，而且对温湿度交叉敏感，数据要做补偿。

我的建议是分档配置。入门档：温湿度加CO2，这两个指标对室内舒适度和通风判断最有用。进阶档：再加PM2.5，适合关注雾霾或者有吸烟、烹饪场景的房间。完整档：再加TVOC，适合新装修的房子做长期监测。不要一上来就全上，传感器越多，I2C地址冲突、供电、固件复杂度的坑就越多，先把核心跑通再逐步加。

2.3 供电与功耗的取舍

Zigbee终端设备最大的卖点之一就是低功耗，可以电池供电。但这里有个现实问题：NDIR二氧化碳传感器和激光PM2.5传感器的功耗都不低，前者工作电流几十毫安，后者带风扇的话上百毫安。如果你要电池供电，就必须做间歇工作，比如每5分钟唤醒一次，采集几十秒，然后休眠。

我的做法是分两种版本。市电版本用USB供电，传感器常开，数据每分钟上报一次，适合固定安装在书房、卧室。电池版本用锂电池加充电管理，传感器间歇工作，数据每5到10分钟上报一次，适合临时放在某个角落做短期监测。两种版本共用同一套固件，只是通过一个配置项切换工作模式。

这里有个细节要注意：ESP32-C6在Zigbee终端设备模式下，休眠电流可以做到微安级，但前提是你把不用的外设都关掉，尤其是射频的保持连接机制要配置对。Zigbee终端设备有两种休眠策略，一种是保持父节点连接（也叫常在线终端），一种是深度休眠需要轮询父节点取数据。前者响应快但功耗高，后者省电但有延迟。对于空气质量监测这种场景，数据本来就是分钟级更新，用深度休眠完全没问题。

3. 开发环境搭建与Zigbee协议栈入门

3.1 工具链怎么装最省事

ESP32-C6的开发，官方主推的是ESP-IDF。我建议直接用ESP-IDF的稳定版本，不要追最新的master分支，因为Zigbee相关的组件在稳定版里更靠谱。安装方式上，Windows用户可以用官方安装器，Linux和macOS用户用git clone加install脚本。装完之后记得跑一下export脚本设置环境变量，不然idf.py命令找不到。

装好ESP-IDF之后，还需要确认Zigbee的组件是否可用。ESP-IDF里Zigbee是以组件形式提供的，通常在components目录下能找到esp-zigbee-lib和esp-ieee802154相关的库。如果你用的是较新的版本，Zigbee SDK可能已经独立成一个仓库，需要单独拉取。这一步很容易卡住，我的经验是直接看官方示例仓库里的Zigbee例子，照着它的依赖配置来，比你自己摸索快得多。

编辑器方面，我个人习惯用VS Code加ESP-IDF插件，代码补全、编译、烧录、串口监视都能在编辑器里完成，省得来回切终端。如果你习惯命令行，那也完全没问题，idf.py menuconfig、idf.py build、idf.py flash monitor这几条命令走天下。

3.2 Zigbee的基本概念先过一遍

在写代码之前，有几个Zigbee的概念必须搞清楚，不然看示例代码会一头雾水。

第一个是设备角色。Zigbee网络里有三种角色：协调器（Coordinator）、路由器（Router）、终端设备（End Device）。协调器是网络的创建者，一个网络有且只有一个；路由器负责转发数据，市电供电；终端设备是叶子节点，可以休眠。我们这个项目做的是终端设备。

第二个是端点（Endpoint）。一个Zigbee设备可以有多个端点，每个端点相当于一个独立的逻辑设备。比如一个多功能的传感器，端点1放温湿度，端点2放CO2，端点3放PM2.5。Home Assistant在识别的时候，会把每个端点下的簇解析成对应的实体。简单项目用一个端点就够了，把所有传感器都挂在端点1下面。

第三个是簇（Cluster）。簇是Zigbee应用层的数据组织单位，每个簇代表一类功能，比如温度测量簇、湿度测量簇、二氧化碳测量簇。每个簇里有一堆属性（Attribute），比如温度测量簇里有一个MeasuredValue属性，就是实际温度值。我们要做的，就是把传感器读数写进对应的簇属性里。

第四个是属性上报。终端设备把数据写进属性之后，需要主动上报给协调器，协调器才知道数据变了。上报方式有两种，一种是主动上报（Report），一种是响应协调器的读取请求（Read）。我们一般用主动上报，配置好最小上报间隔和最大上报间隔，数据变化超过阈值就上报，或者到了最大间隔强制上报一次。

3.3 从官方示例改起是最快的路

我强烈建议不要从零开始写Zigbee固件，而是找一个最接近的官方示例，在它基础上改。官方示例里通常有一个温度传感器或者温湿度传感器的例子，结构非常清晰：初始化Zigbee栈、注册端点、注册簇、配置上报、进入主循环。

拿到示例之后，你要做的改动其实就几处。第一，把示例里的传感器驱动换成你自己的传感器驱动。第二，把示例里注册的簇换成你需要的簇，比如加上二氧化碳测量簇、PM2.5测量簇。第三，把数据上报的逻辑改成读你的传感器再写属性。第四，调整上报参数，比如最小间隔、最大间隔、变化阈值。

这个改法最大的好处是，Zigbee协议栈的初始化、网络加入、安全密钥交换这些复杂的东西你都不用碰，示例里已经调好了。你只需要关注应用层的逻辑，开发效率高很多。我第一次做的时候试图自己从头理解协议栈，结果卡在安全密钥交换那里好几天，后来换成改示例，半天就跑通了。

4. 传感器驱动与数据采集的实操细节

4.1 I2C总线的坑与避坑方法

温湿度、CO2、TVOC这些传感器大多是I2C接口，所以先把I2C总线搞稳。ESP32-C6的I2C外设很灵活，可以映射到几乎任意GPIO，但有几个点要注意。

第一是上拉电阻。I2C是开漏总线，必须有上拉电阻才能正常工作。很多传感器模块自带上拉，但如果你挂多个模块，上拉电阻会并联，阻值变小，可能导致上升沿太陡、信号过冲。我的做法是只保留一组上拉，阻值选4.7kΩ，其他模块的上拉如果可拆就拆掉。如果模块上拉不可拆，那就把总线速率降下来，100kHz通常没问题。

第二是总线电容。I2C总线的电容有上限，一般不超过400pF。线走长了、挂的器件多了，电容就上去了，波形会变圆，通信出错。解决办法是缩短走线、减少挂载器件，或者用I2C多路复用器把总线分段。我一般把传感器集中放在板子一侧，走线尽量短。

第三是地址冲突。不同传感器的I2C地址可能撞车，比如两个器件都是0x44。这时候要么选支持地址切换的型号，要么用多路复用器。买传感器之前一定要把地址查清楚，列个表，避免买回来发现冲突。

4.2 二氧化碳传感器的读取与校准

以NDIR原理的CO2传感器为例，说下读取和校准的细节。这类传感器上电后需要一段预热时间，通常是几秒到几十秒，预热期间读数不可信。固件里要处理这个状态，预热没完成之前不要上报数据，或者上报一个无效标记。

读取的时候，通常是发一条命令，然后等传感器准备好数据，再读回来。命令和数据格式每个型号不一样，一定要对着数据手册写。我踩过的坑是：有的传感器读命令发下去之后需要等一段时间才能读结果，如果你立刻读，拿到的是上一次的数据或者全0。所以固件里要加延时或者轮询状态位。

校准是NDIR传感器的关键。这类传感器出厂时做过校准，但长期使用会有漂移。大多数型号支持两种校准：一种是手动基线校准，你把它放在已知浓度的环境里（比如室外新鲜空气约400ppm），发一条校准命令，它就把当前读数当作基线；另一种是自动基线校准，传感器自己判断什么时候空气最干净，自动调整基线。我建议新装的时候做一次手动基线校准，之后开启自动基线校准，但要注意自动校准要求传感器每天能接触到一次新鲜空气，如果一直放在密闭房间里，自动校准反而会把基线带偏。

4.3 PM2.5传感器的数据稳定性处理

激光PM2.5传感器的原始数据抖动比较大，直接上报会看到数值跳来跳去。处理方式有几个层次。

第一层是硬件层面，保证进气口不被遮挡，风扇转速稳定。有的传感器风扇转速会随电压波动，导致进气量变化，读数跟着变。所以供电要稳，最好单独给传感器一路LDO。

第二层是固件层面，做滑动平均。我一般用一个长度为5到10的滑动窗口，把最近几次读数平均一下再上报。窗口太长响应慢，太短抖动大，5到10是个比较平衡的范围。如果传感器本身支持输出多个粒径通道的数据，可以只取PM2.5那个通道，或者把PM1.0、PM2.5、PM10都上报，让Home Assistant那边做进一步处理。

第三层是上报策略层面，利用Zigbee的变化阈值上报机制。比如设置变化超过5微克每立方米才上报，这样小幅抖动就不会频繁触发上报，既省电又让数据曲线更干净。

4.4 多传感器数据的时间对齐

当你挂了多个传感器，它们各自的采样周期可能不一样，比如温湿度每秒能出一次，CO2每5秒出一次，PM2.5每2秒出一次。如果每个传感器一有数据就上报，Zigbee报文会很碎，而且Home Assistant那边看到的时间戳会乱。

我的做法是在固件里做一个统一的采集周期，比如每30秒采集一轮，把这一轮里所有传感器的最新读数收集齐，然后一次性通过多个簇属性上报。这样Home Assistant收到的是同一时刻的一组数据，做关联分析的时候时间戳是对齐的。实现上可以用一个定时器触发采集，每个传感器驱动提供一个“读取最新值”的接口，主循环里统一调用。

5. Zigbee属性映射与Home Assistant对接

5.1 标准簇和自定义簇怎么选

Zigbee有一套标准簇定义，覆盖了常见的传感器类型。温湿度有专门的簇，CO2有专门的簇，PM2.5也有专门的簇。用标准簇的最大好处是，Home Assistant的Zigbee集成能自动识别，不需要你写任何自定义解析代码，设备一入网，实体就自动出来了。

但标准簇不是万能的。有些传感器指标没有对应的标准簇，比如甲醛、某些特定的TVOC指标。这时候有两个选择：一是用自定义簇（Manufacturer Specific Cluster），自己定义属性和数据格式，然后在Home Assistant里写自定义的解析；二是把数据塞进一个标准簇的未使用属性里，或者用多个标准簇组合表达。

我的建议是，能用标准簇就用标准簇，实在没有再考虑自定义。因为自定义簇意味着你每次换Home Assistant版本、换Zigbee集成，都可能要重新适配，维护成本高。而且自定义簇在别的Zigbee生态里可能完全不认，通用性差。

5.2 属性上报参数怎么配

属性上报的参数配置直接影响到功耗、数据实时性和网络负载，值得仔细调。

关键参数有三个：最小上报间隔（Min Reporting Interval）、最大上报间隔（Max Reporting Interval）、可报告变化量（Reportable Change）。最小间隔是两次上报之间至少隔多久，防止数据抖动导致上报过频。最大间隔是即使数据没变化，也要至少隔多久上报一次，相当于心跳，让协调器知道设备还活着。可报告变化量是数据变化超过多少才触发上报。

以温度为例，我可以这样配：最小间隔60秒，最大间隔3600秒，变化量0.2摄氏度。意思是温度变化超过0.2度就上报，但最快60秒一次；如果温度一直很稳，那至少每小时上报一次。CO2的话，变化量可以设大一点，比如50ppm，因为CO2本身波动就大，设太小会频繁上报。PM2.5变化量设5微克每立方米比较合适。

这些参数不是拍脑袋定的，要根据你的实际场景调。比如你希望CO2超标能尽快触发新风，那最小间隔就要短一点，变化量小一点。如果你只是做长期趋势记录，那间隔可以放长，省电。

5.3 Home Assistant侧的配置与自动化

设备入网之后，Home Assistant里会自动出现对应的实体。如果用的是标准簇，实体名通常是根据簇类型自动生成的，比如sensor.xxx_temperature、sensor.xxx_co2。你可以在Zigbee集成的设备页面里看到所有实体，给它们改个友好的名字，比如“书房温度”“书房CO2”。

接下来就是写自动化。举几个我实际在用的例子。第一个是通风联动：当CO2超过1000ppm持续5分钟，打开新风或者提醒开窗。第二个是净化联动：当PM2.5超过35微克每立方米，打开空气净化器。第三个是舒适度联动：当温度高于26度且湿度高于60%，打开空调除湿模式。这些自动化在Home Assistant里都是几行YAML，触发条件用数值状态触发，动作调用对应的服务。

还有一个很实用的玩法是历史记录和趋势分析。Home Assistant默认会记录实体的历史数据，你可以在仪表盘上放一个历史曲线卡片，看过去24小时或者7天的CO2变化。如果你想把数据长期保存和深度分析，可以接入InfluxDB加Grafana，把数据存到数据库里，做更复杂的可视化和统计。

5.4 网络稳定性与入网问题排查

Zigbee设备入网有时候会不顺利，尤其是第一次配对。常见的现象是设备一直入不了网，或者入网后很快掉线。

入不了网的原因通常有几个。一是协调器的入网权限没开，很多Zigbee集成需要手动点击“允许加入”才会开放一段时间的入网窗口。二是设备离协调器太远，信号太弱，配对阶段建议把设备拿到协调器附近，配对成功后再放到目标位置。三是信道干扰，2.4GHz频段上WiFi和Zigbee会互相干扰，建议把Zigbee协调器的信道设到WiFi用得少的信道上，比如WiFi用1、6、11，Zigbee就用15、20、25这些。

入网后掉线的原因，常见的是信号弱或者路由不稳定。Zigbee是Mesh网络，终端设备会选一个父节点（协调器或者路由器）保持连接。如果父节点信号不好或者断电了，终端设备需要重新找父节点，这期间会掉线。解决办法是在终端设备和协调器之间放几个市电供电的Zigbee路由器，比如智能插座，它们会自动承担路由功能，扩展覆盖。

还有一个坑是终端设备的休眠策略。如果设备配置成深度休眠，它不会一直监听，而是周期性唤醒轮询父节点。如果轮询间隔设得太长，协调器下发的命令可能延迟很久才被设备收到。对于只需要上报数据的传感器，这没问题；但如果你还想让设备接收命令（比如远程触发一次校准），那轮询间隔就不能太长。

6. 常见问题与排查技巧实录

6.1 数据不上报或者上报异常

这是最常见的问题，表现是Home Assistant里实体一直不更新，或者更新了但数值明显不对。

排查思路从后往前推。先看Home Assistant这边，Zigbee集成的日志里有没有收到报文。如果日志里完全没有，那问题在无线链路或者设备端。如果日志里有报文但实体不更新，那可能是实体映射的问题，检查簇和属性的配置对不对。

设备端排查，先看串口日志。固件里一定要打足够的日志，把传感器读数、属性写入、上报触发都打出来。如果传感器读数就是错的，那问题在驱动层，检查I2C通信、命令格式、校准状态。如果读数对但没触发上报，那检查上报参数配置，可能是变化量设得太大，或者最小间隔太长。

还有一个隐蔽的坑是属性类型不匹配。Zigbee属性有数据类型，比如温度是16位有符号整数，单位是0.01度。如果你把浮点数直接写进去，或者单位搞错了，协调器解析出来就是乱码或者离谱的数值。写属性之前一定要对着簇定义确认数据类型和单位。

6.2 传感器读数漂移或者不准

传感器用一段时间后读数漂移，是很正常的现象，尤其是金属氧化物类的TVOC传感器和NDIR类的CO2传感器。

CO2传感器的漂移主要来自光源老化和光腔污染。光源老化是渐进的，表现为读数整体偏低；光腔污染是积灰导致的，表现为读数偏高。前者只能通过定期校准缓解，后者可以拆开清理光腔（如果传感器设计允许的话）。我的经验是每半年做一次手动基线校准，放在室外新鲜空气里校准一次。

温湿度传感器的漂移主要来自湿敏元件的老化和污染。湿度传感器特别怕长期在高湿环境里工作，也怕接触化学溶剂。如果你的监测环境湿度经常超过80%，建议选带加热功能的湿度传感器，定期加热驱潮。另外，温湿度传感器要远离发热元件，比如LDO、MCU，不然测的是板子温度不是环境温度。

PM2.5传感器的漂移主要来自风扇老化和光腔污染。风扇转速下降会导致进气量减少，读数偏低。光腔污染会导致散射光增强，读数偏高。这两个因素叠加，漂移方向不确定。定期清理光腔、必要时更换风扇，是延长寿命的关键。

6.3 功耗高于预期

如果你做的是电池版本，发现续航远低于预期，可以从几个方向排查。

第一，确认设备真的进入了休眠。用电流表测休眠电流，如果还是毫安级，说明有外设没关或者MCU没进低功耗模式。常见的原因是某个GPIO悬空导致漏电，或者传感器没进休眠模式还在耗电。

第二，检查射频的保持连接策略。如果配置成常在线终端，射频会周期性唤醒监听，功耗自然高。改成深度休眠终端，功耗能降一个数量级。

第三，检查上报频率。上报越频繁，射频工作时间越长，功耗越高。如果电池版本，上报间隔可以放到5到10分钟，变化量阈值也可以放宽。

第四，检查传感器的功耗。NDIR和激光传感器是耗电大户，如果它们一直开着，电池根本扛不住。必须让它们也间歇工作，采集完就断电。可以用一个MOS管控制传感器的供电，采集时打开，采集完关闭。

6.4 常见问题速查表

6.5 几个我踩过的坑

第一个坑是I2C上拉电阻重复。我一开始没注意，几个传感器模块都自带上拉，挂在一起之后上拉阻值太小，通信时好时坏。后来把多余的上拉拆掉，只留一组，问题消失。这个坑很隐蔽，因为不是完全不通信，而是偶发错误，很难查。

第二个坑是Zigbee信道和WiFi冲突。我家WiFi用的信道正好和Zigbee默认信道重叠，导致设备入网后经常掉线。后来把Zigbee信道改到WiFi没用的频段，稳定性立刻上来了。这个坑的教训是，部署Zigbee之前先扫一下周围的2.4GHz频谱，避开拥挤的信道。

第三个坑是CO2传感器自动校准把基线带偏。我有一个节点放在卧室，晚上门窗紧闭，传感器自动校准的时候把夜间高浓度当成了基线，结果白天读数整体偏低。后来关掉自动校准，改成定期手动校准，数据才准了。这个坑说明自动校准不是万能的，要看使用场景。

第四个坑是固件里浮点运算的性能。ESP32-C6虽然有硬件浮点，但如果在中断里做大量浮点运算，还是会影响实时性。我后来把浮点运算都放到主循环里，中断里只做标志位，问题解决。

7. 外壳、安装与长期维护的一些经验

7.1 外壳设计要考虑传感器进气

传感器测的是空气，所以外壳必须有合理的进气通道。我的做法是在外壳底部和顶部各开一排小孔，形成对流，让空气自然流过传感器。如果传感器自带风扇，进气口要正对风扇方向，不要被外壳挡住。

外壳材料也有讲究。金属外壳会屏蔽无线信号，Zigbee通信会受影响，所以外壳最好用塑料。如果一定要用金属外壳，天线位置要留出塑料窗口，或者用外接天线。另外，外壳内部要避免形成密闭小腔体，否则传感器测的是腔体内的空气，不是环境空气。

7.2 安装位置对数据的影响

安装位置直接决定数据有没有参考价值。CO2传感器要放在人的呼吸高度，大概离地1到1.5米，不要放在角落或者柜子里。温湿度传感器要远离空调出风口、暖气片、窗户，这些地方测的是局部温度不是房间平均温度。PM2.5传感器不要放在厨房附近，否则做饭的时候数值爆表，但那是局部污染不代表全屋。

我的做法是每个房间的监测节点都放在书桌或者床头柜上，离地1米左右，离墙至少20厘米，远离热源和风口。这样测出来的数据最能代表人的实际感受。

7.3 固件OTA与长期维护

设备装好之后，后续要改固件怎么办？如果每次都要拆下来插USB，那太麻烦了。所以固件里最好加上OTA功能。ESP32-C6支持通过Zigbee做OTA，也支持通过WiFi做OTA。Zigbee OTA的好处是不用额外配网，但速度慢；WiFi OTA速度快，但需要设备同时支持WiFi，会复杂一些。

我的做法是，如果设备是市电供电且位置固定，就加WiFi OTA，需要升级的时候临时开一下WiFi。如果是电池供电或者位置经常变，就用Zigbee OTA，虽然慢但省事。OTA的时候要注意，升级过程中设备会离线，Home Assistant里会显示不可用，升级完成后自动恢复。

长期维护还包括定期检查传感器状态。我一般每个月看一次历史数据，如果发现某个传感器读数明显异常（比如CO2长期在400ppm不动，或者温湿度长期不变），那可能是传感器坏了或者通信断了，需要排查。

7.4 数据长期存储与分析

Home Assistant默认的数据库是SQLite，存几个月的数据没问题，但存几年就会很大，查询也慢。如果你打算长期记录，建议把数据转到InfluxDB，Home Assistant有官方的InfluxDB集成，配置好之后所有实体数据会自动写入。然后在Grafana里做可视化，可以画任意时间段的曲线，做同比环比分析。

我自己的用法是，Home Assistant里只保留最近一个月的数据用于日常自动化和快速查看，长期数据都进InfluxDB，需要深度分析的时候去Grafana看。这样既保证了Home Assistant的流畅，又保留了完整的历史数据。

最后再分享一个小技巧：如果你有多个监测节点，可以在Home Assistant里做一个“全屋空气质量”的综合实体，把各个房间的CO2、PM2.5取平均值或者最大值，用于全局自动化。比如全屋任意房间CO2超过1000ppm就启动新风，这样比每个房间单独判断更符合实际需求。这个综合实体可以用Home Assistant的模板传感器实现，几行配置就能搞定。