LoRaWAN路灯远程控制系统实战：从PWM调光到组播广播-平芜编程栈

在城区路灯这类“点多、线长、面广”的分布式场景里做远程控制，Wi-Fi覆盖成本太高，蜂窝网络虽然信号稳但每盏灯都要一张卡，长期运营下来模块费和流量费叠在一起，管个几百杆灯就先被通信成本压得抬不起头。用LoRa直接发指令，优势在于最后一公里不依赖运营商网络，一台网关能罩住方圆两三公里内的全部灯杆，设备端一个SX1262模块十几块钱就能解决，配合PWM来调亮度，再加上LoRaWAN协议里的单播、组播、广播三种下发通道，基本能覆盖从单灯检修到全城降压照明的全部需求。

我自己搭这套系统折腾了差不多三周，从模块选型到组播参数调通，中间踩了不少坑，也积累了一些可以直接拿去用的经验。如果你正准备做路灯、景观灯、园区照明这类LoRa远程控制项目，这篇内容应该能帮你少走至少一半弯路。

1. 整体方案设计与选型背后的逻辑

1.1 为什么路灯控制要选LoRaWAN

先明确一个前提：路灯控制属于典型的低速率、长距离、海量节点的物联网场景。单灯需要的实时数据量极小，无非是“开”“关”“调亮到百分之几”“上报电压电流”，一个控制帧几十个字节就够用，完全不需要高速率通道。

在通信距离上，市区环境下LoRa也能轻松做到1到3公里，郊区或开阔道路5公里以上都很正常。这个覆盖半径意味着你不需要每个路口都放一台网关，一个片区一台就够，后端通过标准LoRaWAN网络服务器（简称NS）做接入，省掉一大堆现场接线和布网成本。

更关键的一点是设备功耗。路灯本身就是市电供电，设备端其实不缺电，但网关如果布置在灯杆底部或者电箱里，很多时候取电要走原有配电系统，低功耗的好处在于，即使主路断电，网关靠电池或太阳能板也能维持一段时间工作，保证最基本的监控指令还能下发。

不过有一点必须说清楚：LoRaWAN和LoRa不是一回事。LoRa是物理层的扩频调制技术，LoRaWAN是跑在LoRa之上的一整套网络协议，包含设备入网认证、上下行消息格式、频段管理、数据加密这些内容。如果只是想两片LoRa模块之间点对点通信，直接用LoRa裸收发就行，非常灵活；但如果要做“一盏灯对应一个地址、服务器可以精确找到任意一盏灯”的规模化控制，就必须上LoRaWAN，否则地址管理和广播冲突会让你后期维护到崩溃。

1.2 系统的三层架构

整套路灯控制系统在实际落地时分成三层，每一层只解决自己的问题，别把逻辑搅在一起，后面调试会顺很多。

感知应用层就是每盏灯杆上的终端节点，通常由一个MCU加一个LoRaWAN模组组成，MCU负责读取PWM控制脚、检测电流电压、接收下行控制帧，模组负责无线收发。有些方案喜欢把MCU省掉，直接用带LoRaWAN协议栈的SoC（比如ASR6501、SX1262+STM32L0），也可以，但灵活性差一些，后续想接GPS校时或者扩展传感器就比较费劲。

网络传输层包括网关和网络服务器。网关不是简单的“路由器”，它负责把空中的LoRa射频包转换成IP数据包发到后端服务器，同时把服务器下发的数据包再变成射频信号发出去。网络服务器才是真正的“大脑”，设备入网校验、帧计数、确认重传、数据路由这些逻辑都在这里处理。

平台应用层是最终给管理人员看的界面和逻辑，可以是自研的Web端，也可以直接拿光照度曲线、能耗报表这些现成平台改一改。我自己是用Node-RED做了一版轻量级前端，指令通过HTTPS打到网络服务器的API，再走网关下发到灯节点。

这个架构最关键的优势是解耦：灯节点不关心服务器是谁，服务器也不关心灯节点是不是同一个品牌，大家只按LoRaWAN规范说话，后面换任何一端的硬件或软件都不会影响另一端。

2. 硬件选型与PWM调光电路设计

2.1 核心器件清单与选型理由

终端设备我用的是STM32L0系列MCU + SX1268模块这个组合。STM32L0的主频不高，但胜在静态功耗低、带硬件RTC，而且内置12位ADC可以直接采样电流电压。SX1268是国内用得比较多的LoRa射频芯片，支持150MHz到960MHz频段，在CN470频段下发射功率最大可以达到22dBm，实测空旷环境配合3dBi天线能到4公里左右，城市道路环境在1.5到2公里左右，足够覆盖一个中等行政区的路灯网络。

如果预算更紧，也可以用SX1276的老方案，我手头也有一套SX1276的板子，区别在于SX1276只支持FSK和LoRa调制，SX126x系列多了BPSK等调制方式，而且SX126x的接收灵敏度能吃更多信号余量，对功耗控制也更友好。考虑到路灯项目要跑三年五年，我建议还是优先SX126x系列。

网关端我用的是一台SX1302核心芯片的8通道网关。8通道的意思是可以同时接收8个不同频点的LoRa数据包，这个对路灯这种“几十盏灯同时上报心跳”的场景很总要。单通道网关也不是不能跑，只是终端节点需要轮流排队上报，数据量大一点就明显感觉到延迟。

PWM调光驱动电路是关键。我设计的是：

MCU的PA8引脚输出PWM信号，经过一个100Ω电阻直接接到AO3400A MOSFET的栅极
漏极接的是LED灯串的恒流驱动模块控制端
通过改变PWM占空比来改变恒流驱动的有效输出电流

AO3400A是一款SOT-23封装的N沟道MOSFET，导通电阻极低，只有几十毫欧，用于小功率路灯绰绰有余。不要拿三极管直接推大功率LED，压降太大会发热，MOS管才是正解。

2.2 PWM频率与调光曲线的工程取舍

PWM调光最容易踩的坑是频率选择。频率太低，比如200Hz以下，人眼或者摄像头拍视频时会看到明显的频闪；频率太高，比如50kHz以上，MOS管的开关损耗会明显增加，LED驱动模块也可能反应不过来。

路灯照明场合我建议用4kHz到8kHz之间的PWM频率。白天不用开灯，晚上人眼主要感知的是整体亮度稳定度，4kHz以上不会有可感知的频闪，同时又不会让功率管发热到需要额外加散热器的程度。

另外一个容易被忽略的问题是：LED灯珠的亮度和PWM占空比并不是线性关系。人眼对亮度的感知是接近对数的，所以在低亮度档位，比如10%占空比时，你实际感觉到的亮度可能还很亮；但在90%占空比时，亮度变化又会变得不明显。工程上要做一个线性化表格，把“目标感知亮度”映射成“实际PWM占空比”。

我实测的映射关系大致是这样的：

目标亮度	使用伽马校正后的实际占空比
0%（全灭）	0%
10%	约2.5%
30%	约12%
50%	约32%
70%	约58%
100%（全亮）	100%

这个映射不固定，和灯珠特性、驱动电路都有关系，最好用照度计现场标定一遍。我一开始没做这个校正，调光到30%以下时灯的亮度跳变得特别厉害，后来加了查表才平滑。

2.3 恒流驱动选配与调光接口

市面上的LED恒流驱动主要分两种：一种带0-10V调光接口，一种带PWM调光接口，还有一种是电阻调光。路灯项目优先选带PWM调光接口的驱动器，因为直接用MCU引脚就能控制，不需要额外的DA转换电路。

但要注意，有些恒流驱动所谓的PWM调光接口是高电平有效，有些是低电平有效，接反了就会出现“占空比越大灯越暗”的诡异现象。我调试时遇到过这种情况，排查半天最后发现是驱动模块内部用光耦做隔离，光耦输入侧是共阳接法，调了一下逻辑就正常了。

如果驱动模块不带PWM接口，只有0-10V模拟调光口，也可以用PWM加RC低通滤波来产生0-10V电压，不过响应速度会慢几十毫秒，对于路灯这种缓慢调光的场景完全够用。

3. LoRaWAN通信协议与单播、组播、广播实现

3.1 入网方式与参数规划

LoRaWAN的设备入网有两种方式：OTAA（空中激活）和ABP（独立激活）。路灯这种固定位置、数量可控的设备，我推荐用OTAA，原因是安全性更高，每次入网都会重新协商密钥和帧计数，设备被替换后也能安全地重新入网，不会因为密钥泄露导致整网被控制。

如果你只是实验室验证，可以用ABP模式临时试一试，确实省事，因为不需要处理Join请求和Accept流程，但生产环境别这么干。ABP模式最大的问题在于帧计数器是持久化保存的，如果设备重置后计数器不连续，网络服务器会判定为重放攻击而拒绝数据包，排查起来非常头大。

CN470频段下，LoRaWAN规定终端设备使用8个上行频点加3个下行频点的做法，组网参数一般这样配置：

上行频率：486.3MHz到487.9MHz，每个信道间隔200kHz
下行频率：505.5MHz起对应3个下行信道
默认SF12，BW125kHz，ADR开启后会自动从SF12降到SF7
发射功率：默认2dBm，最大22dBm

这里解释一下ADR（自适应速率）的作用。距离网关近的灯，信号好，可以把扩频因子降到SF7，速率提高、占用空中时间变短，整网的频谱利用率就上去了。距离远的灯，保持SF10或SF11，保证通信可靠性。

3.2 单播控制：精确到每一盏灯

单播就是“点对点”的通信方式，网关向指定的一盏灯发下行数据包。LoRaWAN中，每盏灯通过DevAddr（设备短地址）来区分，服务器根据DevAddr找到对应的终端设备，再使用该设备的NwkSKey加密网络层内容、AppSKey加密应用层内容，保证只有那盏灯能正确解密。

在路灯场景里，单播主要用来做单灯检修、定时校时、查看某盏灯的实时电压电流。我定义的控制帧结构长这样：

字节位置	含义	示例值
Byte0	命令字	0x01表示单灯调光，0x02表示查询状态
Byte1	目标亮度	0对应0%，100对应100%，用伽马校正表换算
Byte2	渐变时间	0-255秒，0表示立即动作
Byte3-4	保留字段	备用

这套单播帧用FPort=2下发，应用层自己解析，不影响LoRaWAN协议层。

3.3 组播控制：一条指令控制一片路灯

组播是路灯控制里用的最多的功能，因为实际运维中你几乎不会“一盏一盏”地调灯，而是“一次把整条路的灯调到60%”。LoRaWAN规范里，组播通过给一组设备分配同一个组播地址来实现。

要让设备支持组播，有两个前提条件：

设备必须工作在Class B或Class C模式，因为Class A模式下设备只有上行后的两个短暂接收窗口，服务器很难抓住时机向设备推组播下行数据。
设备需要预先通过配置接口加入某个组播组，也就是写入组播组的DevAddr和对应密钥。

我这边实际使用中，路灯终端统一配置为Class B模式。Class B的原理是网关和终端都通过GPS或网络时间校准到同一个时基，终端每隔一定周期打开一个“ping slot”接收窗口，服务器算好时机在设备打开的窗口内发送下行数据。这样既不像Class C那样必须全时接收导致功耗偏高，又能保证下行数据的及时性。

组播地址配置我用的是0xFC000001到0xFC00000F这一段的组播地址段。规划的时候可以按区域性来分组：

0xFC000001：A区全部路灯
0xFC000002：A区临街路灯
0xFC000003：A区广场路灯
0xFC000101：B区全部路灯

这样一条“调光到50%”的组播命令，一次性就能覆盖整个A区，网关根据组播地址自动完成数据投递。

组播密钥和单播密钥是分开的，组播帧使用组播组自己的NwkSKey和AppSKey加密，这保证即便一个组播组被第三方截获，也无法直接解密其他组播组的数据。

3.4 广播：全网应急控制

LoRaWAN协议本身没有严格的“广播”概念，但在应用层可以采用特殊地址来做全网广播。我用的方法是在组播地址段里预留一个全网广播地址0xFFFFFFFF，所有灯都加入这个“广播组”。

这个广播地址的好处是应急场景特别好用：比如突然暴雨、全城路灯需要立即调亮到100%，或者某个区域出现供电紧张，需要全区域路灯统一降到30%，只发一条下行帧，所有灯同时响应。广播帧不要求ACK重传，因为即便有少量丢包，只要保证大部分灯收到指令，整体效果就达到了，个别没收到指令的灯，靠心跳上报时的单播补发来解决。

广播功能我建议加一个安全限制：只有亮度调节类、开关类指令允许走广播通道，涉及固件升级、参数修改这类操作绝对不能走广播，原因很简单，广播出错影响面太大，而且LoRaWAN的固件升级本身也不适合用广播方式做。

3.5 网络服务器与指令下发流程

网络服务器我用的是ChirpStack，开源的，社区活跃，支持组播很完整。在ChirpStack里配置组播的流程是：

在Tenant下创建DeviceProfile，勾选支持Class B
为每盏灯创建Device，填入DevEUI、AppKey
创建MulticastGroup，填写组播地址、组播密钥、DataRate
将对应Device加入MulticastGroup
使用ChirpStack API或者Web界面向MulticastGroup发送下行数据

下发单条指令时，ChirpStack会计算下一帧帧计数，并把数据交给网关，网关在空中发送，终端在约定的接收窗口收下来解密执行。

我一开始犯过一个错误：创建组播组时DataRate选了SF7，结果覆盖半径外的灯全收不到。后来改成SF10，组播数据用的是较低速率，虽然空中时间变长，但覆盖半径大了一倍多。组播和广播指令用得没那么频繁，牺牲一点时延换可靠性，值。

4. PWM调光控制与终端程序实现

4.1 终端MCU状态机设计

终端程序的核心是一个有限状态机，而不是那种“主循环里瞎忙”的写法。为什么要有状态机？因为路灯终端要处理的事情很多元：要定时上报状态、要监听下行指令、要执行PWM渐变、要检测灯具故障，如果都在一个循环里顺序处理，很容易出现“处理上报的时候正好错过下行窗口”的问题。

我的状态机大致分四个状态：

IDLE：定期发送心跳上报，然后进入低功耗等待
RX_WAIT：等待Class B接收窗口打开
EXECUTE：解析下行指令并执行，比如调整PWM
FAULT：检测到异常，主动上报并尝试恢复

代码结构用C写的话，主循环就一个while(1)加switch状态，每个状态内部设置超时时间，防止卡死。LoRaWAN协议栈本身跑在中断和定时器里，应用逻辑不阻塞协议栈，这是最基本的纪律。

4.2 PWM渐变调光算法

路灯不能一下子从0%跳到100%，一方面是因为LED灯珠突然加大电流会影响寿命，另一方面从人眼感受来说，渐变调光才是“高级”的体验。

我实现的是一个软件渐变算法，每10毫秒更新一次PWM占空比，目标值和当前值之差除以渐变总时间，得到每次调整的步长。

// 渐变调光核心代码 void light_fade_to(uint8_t target_percent, uint16_t fade_ms) { uint32_t current_duty = tim_get_duty(); // 获取当前占空比 uint32_t target_duty = gamma_table[target_percent]; // 查表得到目标占空比 int32_t delta = (int32_t)target_duty - (int32_t)current_duty; uint16_t steps = fade_ms / 10; // 每10ms调整一次 int32_t step_delta = delta / steps; for (uint16_t i = 0; i < steps; i++) { current_duty += step_delta; tim_set_duty(current_duty); delay_ms(10); } tim_set_duty(target_duty); // 最终强制对齐目标值，避免累积误差 }

这里有一个细节值得注意：最后一定要强制设置一次目标占空比。因为步长除以步数后可能会有余数，循环结束时实际占空比和目标值会有几个计数值的偏差，不处理的话，每次调光都会产生微小误差，多调几次亮度就不准了。

4.3 本地故障检测与保护

PWM控制灯亮着，但灯珠烧了一个或者驱动模块故障，从服务器端是看不出来的，所以终端设备必须自己做故障检测。

我在LED恒流驱动的输出回路串了一个采样电阻，通过STM32的ADC实时采集压降，换算出实际电流。正常情况下，PWM占空比和电流是单调对应的，如果发现“占空比很高但电流几乎为零”，基本可以判定为负载开路；如果“占空比很低但电流异常大”，可能是有短路或者驱动失控。

故障状态下，终端会立即把PWM输出拉低到安全值，同时向网络服务器发送一个故障码上行帧。服务器收到后可以自动派单或者直接在平台界面上标红。

ADC采样要注意滤波。路灯驱动电路工作时会有开关噪声，ADC采样的瞬间值跳变得很厉害。我加了50次采样取平均的软件滤波，效果还不错。硬件上在采样脚对地并联一个1uF电容，也能有效抑制毛刺。

4.4 下行指令解析与执行

终端的下行数据处理核心是一个指令分发函数，代码大概是这样的：

void process_downlink(uint8_t fport, uint8_t *payload, uint8_t len) { if (fport == 2) { uint8_t cmd = payload[0]; switch (cmd) { case CMD_SET_LIGHT: { uint8_t target = payload[1]; // 目标亮度 uint16_t fade_time = (payload[2] << 8) | payload[3]; // 渐变时间 light_fade_to(target, fade_time); break; } case CMD_QUERY_STATUS: { report_status(); break; } case CMD_SET_GROUP: { // 动态加入/退出组播组 join_multicast_group(payload[1]); break; } } } }

这里有一个大坑：LoRaWAN的帧计数器（FCnt）是必须严格连续的。如果设备重启后帧计数器没有正确保存，网络服务器会因为收到“旧帧”而拒绝数据。每次下发指令后，终端都要把当前的FCnt写入内部Flash，哪怕Flash写入寿命有限也要写，因为路灯控制不能接受“重启后收不到指令”的情况。

4.5 定时控制与光照联动

光是远程控制还不够，路灯项目还有个很实际的需求是自动开关灯。我的终端设备增加了本地定时任务：

网络服务器每天凌晨同步一次经纬度日落日出时间
终端存下当天的开灯时间和关灯时间
到点自动执行“渐变到90%”或“渐变到0%”

这个设计的好处是，即使网络断开一两天，路灯依然能按时开关，不会变成“断网全灭”或者“断网常亮”的运维事故。

5. 网关部署与下行时序计算

5.1 网关安装位置与天线选型

网关是整网覆盖的关键，位置选不好，终端设备做再多优化都白搭。我总结了几条选址经验：

网关天线尽量高于灯杆顶部的LED灯头，至少和灯头齐平
天线要垂直安装，LoRa天线是全向的，水平放置会让覆盖变成“甜甜圈”形状，头顶和脚下都是盲区
远离大型金属板材和配电箱箱体，至少保持1米以上距离
有条件的情况下网关和天线用馈线分离安装，网关盒放电箱里，天线伸到电箱外

我部署过程中遇到过一个现象：有一台网关装了三天，覆盖范围一直不理想，后来发现是天线被电箱的铁皮挡住了大部分方向。天线从电箱侧壁引出去之后，信号改善了差不多一倍。

5.2 Class B信标与组播下发时机

Class B模式下，终端会定期接收网关发送的Beacon（信标）来校准自己的时间，然后周期性打开接收窗口。这个窗口的参数叫Ping Slot，有几种速率可选，我用的是默认的每32秒一个窗口。

服务器下发组播时，必须等终端打开了接收窗口才能成功接收。ChirpStack实现了这个逻辑：它知道每个终端的ping slot位置，会缓存下行数据等窗口到达。但如果你用的是自研的网关和NS，这里就得自己实现窗口计算了。

计算ping slot的公式可以简化成：

// 以Beacon周期为基准，计算每个终端的接收窗口时间 // 实际公式来自LoRaWAN规范，这里是简化实现 uint32_t cal_ping_slot_offset(uint32_t devaddr_hash, uint8_t ping_slot_periodicity) { uint32_t num_slots = 1 << ping_slot_periodicity; // 每周期时隙数 uint32_t slot_index = devaddr_hash % num_slots; return slot_index * (128000 / num_slots); // 返回相对于Beacon的毫秒偏移 }

这段计算如果做错了，最常见的结果是：终端有时能收到组播、有时收不到，看起来就像“丢包率特别高”。其实不是丢包，是服务器和终端的时隙根本没对上。用ChirpStack的时候完全不用管这个，它内置了Beacon同步逻辑，我最早用自研协议栈的时候被这个坑折磨了整整两天。

5.3 网关上行数据可视化管理

系统正式运行起来后，每个终端的工作状态、信号质量、电压电流数据都会通过心跳帧周期性地发到服务器。我建议心跳上报周期设为10分钟一次，太频繁会占满上行信道，太稀疏又无法及时发现故障。

ChirpStack带了一个内置的网关页面，可以看到每台网关的接收数据包数量、网关RSSI、信噪比等指标，还能查看每个终端设备的最近上行时间。把这些和Grafana接在一起，可以做一个大屏看板，路灯状态一目了然。

6. 常见问题排查与避坑经验

6.1 下行指令收不到

这个是最常见的故障类型，我从三个方向排查：

第一，确认终端设备当前的接收模式。如果设备是Class A，只有在主动上行之后的1秒和2秒才有两个接收窗口，服务器在窗口外下发数据，终端根本收不到，只能等下一次上行。这时候服务器端会显示下行数据发送成功了，但设备端没有任何反应。要把设备切换到Class B或者Class C模式才行。

第二，确认帧计数器。LoRaWAN的FCnt如果不同步，会导致设备直接丢弃下行帧。查看设备内部保存的FCnt和服务器记录的FCnt相差是否很大。我当时排查过一个案例，设备换了新Flash芯片后FCnt清零了，服务器里还记着旧值，所有下行帧都被当成重放攻击丢弃。

第三，确认组播密钥是否匹配。单播和组播用不同的Session Key，设备如果只加入了单播分组，没有加入组播分组，组播下行帧同样收不到。这个得在设备侧写一条“查看加入的组播分组”的调试命令，一条条核对。

6.2 组播收不到但单播正常

如果单播正常、组播偶尔收不到，大概率是Class B时隙不同步。原因可能是设备所在区域Beacon接收不好，无法正常校准时间，或者设备的晶振偏差较大。

解决办法：在终端内部增加Beacon状态监测，连续几个Beacon周期没收到就做一次重新入网（Rejoin）。另一个办法是加大Class B的Beacon接收失败容错次数，让设备不会因为短时干扰就掉出Class B状态。

6.3 PWM调光频闪和偏差

调光到50%以下出现肉眼可见的频闪，通常是PWM频率太低。用示波器抓一下MCU引脚波形，如果频率低于2kHz，把定时器分频值调一下，升到4kHz以上。

如果亮度偏差大，比如目标60%实际看起来像80%，那就是没做伽马校正。用一个照度计记录不同占空比下的实际亮度，重新拟合映射表，问题立刻解决。

6.4 现场距离和信号衰减不理想

有的灯在远距离时收不到信号，尤其是雨天或者周围有密集树木遮挡。这类问题的思路是：

把终端发射功率调到最大22dBm
把组播下行速率从SF7降到SF10
检查天线接头是否拧紧，SMA头虚接是射频信号衰减的大杀器
如果实在覆盖不了，在这个区域新增一台低成本单通道网关，专门负责近处的灯

6.5 蜂窝网络和Wi-Fi方案的对比教训

在方案选型阶段，我们也考虑过用4G Cat.1模组做单灯控制。当时对比下来，Cat.1模块单片价格在30元上下，比LoRa模块贵一倍左右，而且每年每盏灯要交流量费，按1GB年包最低也要十几块钱。1000盏灯一年光流量费就是一万多。LoRa的模块成本、流量成本全为0，自己维护一台网关的电力网费一年也就几百块。当然LoRa不是万能的，城区高层建筑多的小区域、单个网关覆盖不了的场景，Cat.1反而省事。但就路灯这种规律性很强的场景，LoRaWAN的综合性价比确实最高。

7. 后续扩展空间与我的个人体会

这套系统跑稳之后，可玩性其实还有很多。比如在同一个终端上加装光照度传感器，亮度不够自动补光；加装单灯计量模块，把每盏灯的电量上报到平台做能耗分析；或者把组播分组从“按区域”改成“按车流时段”，实现深夜车流量小时自动降低一半亮度，还能进一步节能。

组播地址的规划最好在一开始就想清楚，别等设备已经批量部署了再改。虽然LoRaWAN支持设备动态加入和退出组播组，但如果几百盏灯都已经写死在固件里，后期改分组要一台一台重新配，工作量巨大。在规划阶段就把“区域+类型+序号”的编码规则定下来，能省后面很多事。

我个人在实际操作中体会最深的一点是：LoRaWAN这套协议栈本身并不复杂，但它是“链路层协议+应用层业务”深度耦合的活儿，任何一个环节想当然，都能让线上系统花很长时间来买单。比如那个伽马校正，我一开始以为是锦上添花的功能，直到现场调试时发现低亮度档位完全不可用才开始重视。再比如Class B的时隙同步，如果用的不是ChirpStack这种成熟NS，自己实现时务必做好设备的时钟漂移校准，不然组播功能就只能停留在PPT里。

如果你正准备上手这个项目，我建议先把单个灯节点的PWM调光和单播控制跑通，再上组播，最后再搞广播。别急着一次到位，按这个节奏推进，每个环节留出足够的时间去调试和验证，整个系统会稳得多。

LoRaWAN路灯远程控制系统实战：从PWM调光到组播广播