二、系统总体架构设计：星型拓扑 vs 网状拓扑、主控节点与子节点职责、通信协议选型
好，咱们进入正题。系统架构设计，说白了就是决定「谁听谁的、怎么传话」。我见过不少团队一上来就选协议、画板子，结果做到一半发现通信距离不够，或者节点多了就卡死。嗯，这步走稳了，后面才省心。
2.1 拓扑结构：星型 vs 网状，怎么选？
先聊拓扑。灌溉控制器这种场景，节点通常固定不动，不像无人机编队那样需要动态组网。所以选择其实很明确：星型还是网状？
星型拓扑
我个人习惯在中小型项目里用星型。结构简单，一个主控节点管所有子节点。子节点只管收指令、干活、回状态。主控节点负责调度、决策、异常处理。
优点：
- 延迟低，主控直接发，子节点直接收，没有多跳
- 故障隔离好，一个子节点坏了不影响其他
- 软件协议栈简单，省内存
缺点：
- 覆盖范围受限于主控的发射功率
- 主控是单点故障，一旦挂了整个系统瘫痪
我在项目里遇到过这种情况：一个农场有30个电磁阀，分布在200米半径内。用星型拓扑，主控放在中间，LoRa一发全收，稳得很。但如果农场有500亩，星型就吃力了——边缘节点可能丢包。
网状拓扑
网状拓扑的好处是每个节点都能转发。子节点之间可以互相传话，最后汇聚到主控。说白了就是「人传人」模式。
优点：
- 覆盖范围大，通过多跳扩展
- 自愈能力强，某个节点坏了，数据自动绕路
缺点：
- 延迟不确定，跳数多了可能秒级延迟
- 协议栈复杂，每个节点都要维护路由表
- 功耗高，因为要监听和转发
我曾经在一个山坡果园里试过Zigbee网状网络。结果发现，果树遮挡严重，节点之间经常断链，路由表重建频繁。嗯，后来还是改回了星型+中继器方案。
我的建议：灌溉场景优先考虑星型。如果覆盖不够，加中继节点（也叫网关扩展器），而不是让所有子节点都参与路由。这样既简单又可靠。
2.2 主控节点与子节点职责划分
职责不清是项目翻车的常见原因。我见过有人把子节点设计得特别「聪明」，结果每个节点都要跑复杂的调度算法，成本翻倍，还容易死机。
主控节点（Coordinator / Gateway）
- 决策中心：根据土壤湿度、天气预报、时间表，决定什么时候浇、浇多少
- 通信调度：轮询或广播方式，给子节点下发指令
- 异常处理：检测子节点是否离线、阀门是否卡死、流量是否异常
- 数据存储：记录灌溉日志、传感器历史数据
- 人机交互：连接触摸屏或云端，供用户查看和设置
子节点（End Device / Actuator）
- 执行指令：收到开阀指令就开，收到关阀指令就关
- 状态上报：定期或按需上报阀门状态、电池电量、传感器读数
- 本地保护：如果长时间收不到主控心跳，自动关闭阀门（防失控）
- 低功耗管理：大部分时间休眠，定时唤醒或外部中断唤醒
注意：子节点不要做复杂决策。比如「根据土壤湿度自动开阀」这种逻辑，应该放在主控。为什么？因为子节点没有全局视野，可能一个区域浇多了，另一个区域还干着。我曾经吃过这个亏，后来全改回主控集中调度。
2.3 通信协议选型：LoRa vs Zigbee vs WiFi
选协议就像选工具——螺丝刀再好也不能当锤子用。咱们直接看对比表：
| 特性 | LoRa | Zigbee | WiFi |
|---|---|---|---|
| 通信距离 | 1-10km（视距） | 10-100m（室内） | 30-100m（室内） |
| 功耗 | 极低（休眠μA级） | 低（休眠μA级） | 高（mA级） |
| 数据速率 | 0.3-50kbps | 250kbps | 11-300Mbps |
| 网络拓扑 | 星型为主 | 网状为主 | 星型 |
| 成本 | 中等（模块约20-50元） | 低（模块约10-30元） | 低（模块约10-20元） |
| 抗干扰 | 强（扩频技术） | 中等（2.4GHz频段拥挤） | 弱（同频干扰多） |
| 适用场景 | 大田、果园、远距离 | 温室、大棚、短距离组网 | 有市电、近距离、高带宽 |
LoRa——我的首选
说实话，做灌溉控制器，LoRa是我最常用的方案。为什么？
- 距离够远：大田里几百米到几公里，一个主控能覆盖整个农场
- 穿墙能力：虽然比不上Sub-1GHz的私有协议，但比2.4G的Zigbee/WiFi强太多
- 功耗极低：子节点用两节AA电池，撑一个灌溉季没问题
- 抗干扰：扩频技术，在电机、变频器附近也能稳定通信
我记得有一次在养猪场做项目，Zigbee死活连不上，因为猪舍里的金属围栏和潮湿环境严重衰减信号。换成LoRa后，从办公室到最远的猪舍800米，一次搞定。
Zigbee——适合密集节点场景
Zigbee的优势在于组网能力。如果你有上百个节点，且分布在一个温室里（50米半径内），Zigbee的网状网络可以自动路由。但要注意：
- 每个节点都要参与路由，功耗比LoRa高
- 2.4GHz频段和WiFi重叠，干扰严重
- 调试起来麻烦，路由表重建时可能丢包
我曾经在一个花卉大棚里用Zigbee，50个节点，刚开始好好的。后来客户加了个WiFi摄像头，结果Zigbee网络直接瘫痪。嗯，从那以后我对2.4GHz频段就多留了个心眼。
WiFi——只推荐有市电的场景
WiFi的好处是带宽大、生态好、可以直接连云端。但功耗是硬伤。如果你每个阀门旁边都有220V电源，那用WiFi没问题。否则，电池供电的节点用WiFi，几天就得换电池。
我一般只在主控节点上用WiFi（连接云端），子节点坚决不用。你想想看，一个电磁阀控制器，装在地里，拉根网线？不现实。
我的选型口诀：
- 大田、远距离、电池供电 → LoRa
- 温室、密集节点、短距离 → Zigbee
- 有市电、需要视频/大数据 → WiFi
- 混合方案：主控用WiFi/4G连云端，子节点用LoRa/Zigbee连主控
2.4 实战中的避坑指南
最后分享几个我踩过的坑：
- 别迷信理论距离：LoRa标称10公里，那是视距、无干扰的理想情况。实际农田里有树木、地形起伏，能到2-3公里就不错了。我建议按标称值的30%做设计。
- 天线位置很重要：子节点如果埋在阀门井里，金属井盖会屏蔽信号。我吃过这个亏，后来所有子节点都外接天线，或者把天线引到井口。
- 预留冗余：主控节点至少留一个备用通信通道。比如主用LoRa，备用RS485有线。万一无线干扰严重，还能切有线。
- 心跳机制不能省：子节点每隔一段时间（比如5分钟）给主控发心跳。如果主控连续3次没收到，就认为子节点离线，触发报警。我曾经因为没做心跳，一个阀门卡死在开启状态，流了一夜的水。
好了，系统架构设计就聊到这儿。下一章咱们会深入硬件选型，聊聊主控芯片、射频模块、电源管理这些实战细节。到时候我会拿我实际用过的几款芯片做对比，保证干货满满。