sACN（E1.31）灯光网络协议速查
依据 ANSI E1.31（由 ESTA 技术标准委员会发布）公开标准整理，具体设备支持以厂商手册为准。
从一次”半场灯不亮”说起
整馆换了套网络灯控，控台一推场景，一楼灯全亮、二楼那片死活不动。网线通、灯具能 ping、控台也在发数据——一切看着都对，就是二楼收不到。最后翻到接入交换机上，二楼那台的 IGMP Snooping 是开着的，但全网没有一个设备在做 querier，组播表老化后交换机干脆把 sACN 的多播流全丢了。这类”网络通着、灯却不亮”的怪事，几乎是 sACN 现场最典型的坑，病根不在协议本身，而在你把 DMX 搬上以太网之后，多了组播和交换机这两层要伺候。这篇把 sACN 的地址算法、优先级、组组网要点讲透，让你下次遇到半场不亮能顺着链路一层层排下去。
sACN 是什么
sACN（Streaming ACN，流式 ACN）是 ANSI E1.31 标准定义的「DMX over IP」灯光网络协议，由娱乐服务与技术协会（ESTA）制定，在专业灯光领域被广泛采用。它把 DMX512 的 universe（每个最多 512 通道）封装为 UDP 包在网络上「持续流式」发送，即使通道值不变也会不断刷新，确保接收端状态不会「冻结」——这点很关键，接收端可以设一个超时（常见几秒），超时没收到新包就判定数据源掉线，转而听备用源或保持最后状态，主备切换的基础就在这。
为什么要把 DMX 搬上网
一条物理 DMX512 只有 512 通道，跑 RS-485 铜缆几百米就到头，整馆几百盏 RGBW 灯早就撑爆。sACN 把每个 universe 打成 UDP 包丢进以太网，一根网线经交换机就能承载几十上百个 universe、跨楼层跑，末端再由网关解回物理 DMX 喂灯，把”通道不够、距离受限”两个物理层硬伤一次解掉，还白捡了组播分发和优先级仲裁两样 DMX 时代没有的能力。
关键参数
| 项目 | 值 |
|---|---|
| 标准号 | ANSI E1.31（2016 / 2018 版） |
| 传输方式 | UDP，多播为主，亦支持单播 |
| 默认端口 | UDP 5568（已正式向 IANA 注册） |
| 字节序 | 网络字节序（大端，big-endian） |
| universe 容量 | 每 universe 最多 512 通道 |
| universe 编号 | 1–63999（0 与 64000+ 保留） |
| 多播地址 | 239.255.{高字节}.{低字节} |
| 优先级 | 0（最低）–200（最高），默认 100 |
| 组播订阅 | 接收端用 IGMP 订阅对应 universe |
| 数据源超时 | 约 2.5 秒无包判定源掉线（标准建议值） |
| 制定方 | ESTA |
工作原理：地址算法与优先级
sACN 以多播为核心传输方式。每个 universe 对应一个固定多播地址，算法很直白：
universe = 高字节 × 256 + 低字节
多播地址 = 239.255.<高字节>.<低字节>
例：universe 1 → 239.255.0.1
universe 256 → 239.255.1.0
universe 511 → 239.255.1.255
这个映射是标准写死的，所有厂商设备都按这套算，不用手工配 IP。接收端通过 IGMP「订阅」自己关心的 universe 多播组，交换机据此只把相关流量送到需要的端口，避免广播泛滥——这是 sACN 相对 Art-Net 广播模式最实在的省带宽优势。
每个 sACN 包都带 0–200 的优先级：当同一 universe 同时有多个数据源在发，接收端认优先级高者的数据生效，优先级相同则看具体实现（多为先到源保持）。数据源掉线（超时约 2.5 秒收不到包）后，接收端才转听次高优先级的源。主备控台无缝接管就是靠这个：主控发优先级 100，备控发 90，平时听主控，主控一死备控自然顶上，切换过程灯不会闪黑。数据约每若干十毫秒重发一次，单包丢失能很快被后续帧补上，这也是”流式持续发送”设计的用意。
展厅实战：怎么把 sACN 组进中控网
展厅里 sACN 极少单独存在，链路通常是：中控主机 → 交换机（组播网）→ sACN 网关（Ethernet-to-DMX 节点）→ 物理 DMX 链 → 灯具。几个落地要点：
- 网络要能扛组播：接入层交换机开 IGMP Snooping，全网至少有一个 IGMP querier（通常在核心交换机或路由上配），否则组播表老化后就是开头那个”半场不亮”。灯控网建议单独划 VLAN，跟办公/监控网隔开，免得组播流互相污染。
- universe 规划落文档：网关上每个物理 DMX 口对应一个 universe 号，编号表要跟灯光地址表一起贴弱电间。网关和中控软件两头的 universe 号必须对上，这是”网络通、灯不亮”的头号排查点。
- 中控封装成场景：sACN 的通道值由 SoftControl 展厅中控 预存为”开馆/讲解/聚焦/闭馆”等灯光场景，按时间表或按钮触发，配合 SoftPlayer 展厅播控 做灯光跟多媒体动线联动。
- 主备冗余：重要场馆用两台控制器发同一批 universe、设不同优先级，主控故障自动接管，这套思路跟 DMX512 时代的物理备份比，省线又省心。
这套”底层协议屏蔽、对外只暴露场景”的封装思路，跟 Modbus 设备控制 里控窗帘门禁一脉相承，运营人员不用懂 universe，点一下按钮就行。
sACN vs Art-Net：到底怎么选
两者都是把 DMX 搬上以太网，同一张灯控网里也常并存，选型看几个硬差别：
| 维度 | sACN（E1.31） | Art-Net |
|---|---|---|
| 端口 | UDP 5568，已向 IANA 注册 | UDP 6454，未注册 |
| 默认传输 | 组播（省带宽） | 广播（大网易风暴） |
| 优先级仲裁 | 内建 0–200 优先级 | 无原生优先级机制 |
| 生态历史 | 官方标准，起步稍晚 | 出现更早，网关支持面最广 |
| 适用场景 | 大型纯灯控网、要冗余 | 混合工程、老设备兼容 |
一句话：大型纯灯控网、要做主备冗余，优先 sACN；现场有一堆只认 Art-Net 的老网关，或工程规模不大，Art-Net 更省事，实际很多项目二者并存——中控同时发两种，哪台网关认哪种就喂哪种。选之前先确认现场网关和中控软件两头都支持你要用的那个。详见 Art-Net 协议速查。
故障排查表
| 现象 | 可能原因 | 排查 / 解决 |
|---|---|---|
| 部分区域灯完全不亮，网络却通 | 交换机 IGMP Snooping 开了但全网无 querier，组播被丢 | 核心交换机/路由配 IGMP querier，或临时关 Snooping 验证 |
| 某几个 universe 收不到 | 网关与中控的 universe 编号不一致 | 对照 universe 编号表逐口核对 |
| 主控故障后备控没接管 | 两台源优先级设成一样，或超时没触发 | 主备设不同优先级，确认掉线超时生效 |
| 灯偶发抖动、卡顿 | 灯控网跟其他业务混跑，组播被大流量挤 | 灯控单独划 VLAN，给 sACN 流量做 QoS |
| 跨三层（路由）后收不到组播 | 路由默认不转发多播 | 配组播路由（PIM/IGMP proxy）或改单播模式 |
| 全网灯都收不到 | 端口 5568 被防火墙/ACL 拦，或源根本没发 | 抓包看 5568 有无流量，放行端口 |
排查口诀：先确认源在发（抓 5568），再看组播能不能到（IGMP/querier），最后才核 universe 编号对不对。
进阶与边界
单播模式：小规模或点对点场景可让 sACN 走单播，绕开组播那套 IGMP 配置，代价是失去”一份数据多点订阅”的省带宽优势，网关多了源端负担重。
跨三层组播：sACN 组播默认在二层广播域内活动，要跨路由（不同网段）分发，得在路由上启用组播路由，否则组播过不去——这也是灯控网普遍拍平成一个大二层 VLAN 的原因。
与 Art-Net 混发：同一网关常同时收 sACN 和 Art-Net，注意别让两种协议对同一 universe 同时发数据，否则接收端行为看实现、容易打架。规划时明确每个 universe 归谁管。
动手检查清单
- 灯控网单独划 VLAN，接入交换机开 IGMP Snooping
- 全网至少一个 IGMP querier，跨三层已配组播路由
- 网关与中控两头 universe 编号已对齐、落文档
- 防火墙/ACL 放行 UDP 5568
- 需冗余的场馆主备控台设了不同优先级并测过切换
- 灯光场景已在中控预存并测试触发
小结
sACN 的本质是把 DMX universe 装进 UDP 组播包持续流式发送，核心就三样：239.255.高.低的地址算法、0–200 优先级仲裁、IGMP 组播订阅。它比 Art-Net 多了注册端口、组播省带宽和原生优先级，适合大型灯控网和主备冗余。但把灯搬上网也意味着你得伺候好交换机的组播——现场八成毛病不在协议，在 IGMP 和 querier。上层再由中控把通道值封装成场景，灯光才真正接进展厅叙事。
延伸阅读：DMX512 灯光控制协议、Art-Net 协议速查、Modbus 协议 与 TCP/UDP 通信基础，或查看全部设备协议速查。
需要把 sACN 灯光网络接入展厅统一编排？了解 SoftControl 展厅中控系统，查看解决方案与落地案例，或直接联系我们聊聊你的定制需求。