当前位置: 首页 > news >正文

DALI的无线世界:你真的分清楚了吗?

说起DALI,做照明的朋友应该都不陌生——两根线,数字调光,开放标准,全球通用。这套协议从1990年代末诞生至今,撑起了无数商业楼宇的智能照明系统。

但DALI有个老毛病,大家心里都清楚:它是有线的

所以当DALI联盟(DiiA)在2021年5月宣布推出DALI+的时候,很多人松了一口气:终于无线了!

……等等,这里其实有两个不同的东西经常被混为一谈,今天来把它们掰扯清楚。



两个概念,别再搞混了


DALI+:把DALI搬上IP网络

DALI+的核心思路是"协议不动,换条路走"——用IP网络(Ethernet、Wi-Fi、Thread)来承载DALI命令。

关键点在于:DALI+走的是原生IP路线。协议栈里的传输层直接用了TCP/IP、UDP这些东西,DALI命令被封装进IP数据包,在Ethernet、Wi-Fi或Thread(仅支持IPv6)这些介质上原生传输。

所以DALI+的传输介质可以是:

  • Ethernet(有线)

  • Wi-Fi(无线)

  • Thread(无线,基于IPv6)

不过要实话实说:截至目前,真正落地实际部署的DALI+方案只有Thread。Ethernet和Wi-Fi在规范层面是支持的,但市面上还没有看到成熟的商业产品。所以给人一种错觉——DALI+好像就是无线的。实际上,DALI+是一套覆盖有线IP和无线IP的技术框架,Thread只是目前走得最快的那条路。

Wireless DALI:一个更大的概念

Wireless DALI是DALI技术无线应用的总称,包含两条不同的技术路线:

路线一:DALI+就是上面说的,用IP网络承载DALI——Wi-Fi和Thread属于这一类。

路线二:无线转DALI网关这是另一套思路——蓝牙Mesh、Zigbee这些无线协议,本来和DALI完全不兼容,怎么办?加一个"翻译官"(网关),把无线网络的控制命令翻译成DALI命令,反之亦然。

这条路线对应的是Part 341(蓝牙Mesh网关)和Part 352(Zigbee网关)规范。

所以 Gateway 和 Part 104 定义的系统级 alternative transport layer(替代传输层)有着根本性的区别

  • Gateway:两种协议互相翻译,桥接互通

  • Part 104 / DALI+:DALI协议直接跑在IP上,不做翻译,是原生集成


技术上怎么理解?

用一个简化的对比来看 DALI+ 的协议栈:


Wireless DALI 的另一条路(Gateway 方案):

DALI+是把DALI命令直接装进IP包,Gateway是在两套不同协议之间来回翻译——原理完全不同。


所以 Part 341 和 Part 342 是什么?

很多资料里提到 Part 341 和 Part 342,这两个规范搞的就是 Gateway 这条路:

规范内容
Part 341蓝牙Mesh转DALI网关规范
Part 342Zigbee转DALI网关规范

网关的作用:

  • 把蓝牙Mesh或Zigbee发来的控制命令,翻译成DALI总线命令

  • 也可以把DALI设备的状态、能耗数据,反馈给无线侧

这样一来,现有的DALI-2设备不需要换,加一个网关就能接入蓝牙Mesh或Zigbee生态,灵活性大增。

DALI+ Thread:两个概念的交汇点

Thread比较特殊,它同时属于两条路线:

  • 作为DALI+的传输介质:Thread基于IPv6,DALI命令可以直接封装在Thread数据包里传输,不需要网关——这是原生的DALI+路线

  • 通过Gateway接入:如果你的系统里用了蓝牙Mesh或Zigbee的设备,可以通过 Part 341/342 的网关接入DALI系统

所以Thread既是DALI+的原生介质,也可以走Gateway那条路。区别在于你是直接用DALI+ Thread,还是用Thread设备通过蓝牙Mesh/Zigbee再转DALI。

DALI-2、D4i、DALI+、Wireless DALI,一次说清楚


名称走的线/介质技术路线干什么用的
DALI-2有线DALI总线协议层照明控制核心标准
D4i有线DALI总线(灯具内部)协议层数据扩展:能耗、诊断、资产信息
DALI+Ethernet / Wi-Fi / Thread(IP网络)原生IP传输把DALI命令跑在IP上
Wireless DALI蓝牙Mesh / Zigbee(通过网关)Gateway桥接无线生态与DALI的互联互通

三者不是竞争关系,是互补的:

  • DALI-2是基础

  • D4i在DALI总线上加了数据能力

  • DALI+去掉线,用IP承载(目前落地只有Thread,Ethernet和Wi-Fi待发展)

  • Wireless DALI(Gateway路线)用翻译器连接蓝牙Mesh/Zigbee生态


往后看:DALI+和Matter

如果你关注智能家居,一定听说过Matter——苹果、谷歌、亚马逊联合推的智能家居统一标准。

Thread确实是Matter的核心传输层,而DALI+ Thread也跑在Thread的IPv6/UDP之上。但这只是底层物理/传输层相同,应用层协议完全不同

  • Matter用的是自己的应用层协议和设备模型(Device Library)

  • DALI+用的是IEC 62386定义的那套DALI照明控制命令

所以,DALI+ Thread要融入Matter生态,并不是"天然就能",而是需要额外的网关来做协议翻译,把Matter的命令转换成DALI命令,反之亦然。

问题在于:截至目前,DALI联盟内部尚未推进Matter Gateway的标准化工作。DALI联盟现有的两个Gateway规范——Part 341(蓝牙Mesh网关)和Part 342(Zigbee网关)——都是针对蓝牙Mesh和Zigbee的,并不覆盖Matter。

还有一种更激进的路子:让DALI+ Thread的设备同时支持DALI+和Matter双栈。但这实际上挑战很大——两个标准在设备模型、认证要求、功能定义上都有各自的规范,同时满足两边的要求很可能出现冲突,设备开发的复杂度会大幅增加。

所以更现实的判断是:Matter和DALI+的融合,目前既没有Gateway规范支撑,也没有双栈融合的成熟路径,更多停留在理论探讨阶段。能不能真正打通,要看DALI联盟和Connectivity Standards Alliance(CSA/Matter标准组织)后续是否愿意联合推进。

IEC 62386-105(2020版)已经纳入了固件更新标准,DALI+设备支持OTA升级,对无线设备的长期维护是个有用的基础能力。

小结

DALI的无线化走了两条路:

  1. DALI+:DALI命令直接跑在IP网络(Ethernet、Wi-Fi、Thread)上,原生集成,不做翻译

  2. Wireless DALI(Gateway路线):蓝牙Mesh、Zigbee通过Part 341/352 网关与DALI互联,协议翻译

两条路各有各的用武之地。DALI+适合新项目、直接用IP生态的场景;Gateway路线适合存量项目、需要接入已有无线生态的场景。

另外要记住:DALI+ 不等于无线,目前真正落地的只有 Thread。Ethernet 和 Wi-Fi 在规范上是支持的,但市场上还需要时间发展。

搞清楚这两个概念,后面聊技术细节才不会鸡同鸭讲。

用大力哥的话说:无线DALI的世界没那么复杂,搞清楚谁在翻译谁、谁在原生跑就行了。

参考资料

  1. DALI联盟官网 https://www.dali-alliance.org/

  2. DALI联盟发布DALI+技术(2021.05)

  3. DALI联盟携手Thread开发DALI+ Thread(2021.06)

  4. DALI联盟发布无线转DALI网关规范(2021.04)

  5. IEC 62386系列标准、DiiA规范文档

  6. DiiA Specification Part 341/342(Bluetooth Mesh/Zigbee Gateway)


南京美加杰智能科技有限公司(Meijay Technologies Co., Ltd.)是一家位于江苏南京的专业智能照明解决方案厂商,是多个智能照明和物联通信标准组织会员,研发和生产包括基于DALI、 RDM/DMX、matter、Ethernet IP、RS485等多种物联网和智能照明通信协议的照明控制模块、照明控制器、照明传感器和照明控制系统等软硬件产品,同时还为客户提供产品定制开发和产品测试认证等专业服务。

公司2018年即相继加入DALI联盟和 Zhaga (灯具组件接口标准化组织),是DALI CFG(DALI联盟中国焦点组)技术合作伙伴,参与《DALI技术手册》编写。公司寻求通过将各种物联网通信技术和智能照明市场的需求结合进行落地,使得灯具、控制装置、传感器等照明终端产品通过我们提供的一站式服务升级后,具备可连接、可编程、可交互的特性,快速融入到智能照明和物联网的应用环境。

公司还是台达楼宇自控系统和智能照明系统的授权高级渠道商,台达旗下LOYTEC品牌的楼宇控制系统产品,适用于工厂、车站和商业建筑等大型智能控制应用场所。


关注公众号,回复“资料共享”获取最新DALI标准协议资料。

http://www.jsqmd.com/news/658789/

相关文章:

  • Mind+学习和项目栈1
  • 踩坑分享IntelliJ IDEA 打包 Web 项目 WAR 包(含 Tomcat 部署 + 常见问题解决)
  • 手绘风格虚拟白板Excalidraw:5分钟开启无限创意协作
  • Qwen3.6‑35B‑A3B:30B 激活参数的“全能编码智能体”来了!
  • 从8051到RISC-V:用蜂鸟E203开源核做IoT项目,这份Windows环境搭建指南请收好
  • 深入RK3588启动流程:从Maskrom到Linux,揭秘每个固件镜像的职责与交互
  • 别再手动Review AI代码了!这套基于CodeBERT+RuleGraph的实时风格校验流水线,仅剩最后47个Early Access名额
  • OpenClaw部署与调用本地部署的大模型
  • 混合储能蓄电池、超级电容三相并网+电池管理simulink仿真模型
  • 构建智能能源管理系统的7个关键技术突破:OpenEMS实战指南
  • 简单理解:M-Bus (Meter-Bus,仪表总线)
  • mysql如何配置监听IP_mysql bind-address多地址设置
  • PeerConnection深度解析一:CreateOffer
  • 对比分析DeerFlow和Hermes的记忆/技能进化系统
  • 别再手动炒股了!清华博士教你用 AI Agent 搭建量化交易系统(附源码)
  • 对话开发者:除了爆款,我们还能拿出什么样来对抗大环境的冷?
  • Fastjson的AutoType:从‘得力助手’到‘安全噩梦’,我们该如何用SafeMode优雅收场?
  • noi-2026年4月14号作业
  • 实操分享:为什么【灵智AI站群】能实现百万收录?亲自测试
  • 手把手拆解记分牌(Scoreboard)硬件:如何用Python模拟一个简单的ILP调度器?
  • 单片机串口通信入门:手把手教你配置TMOD、SCON和SBUF寄存器(附代码)
  • 从“完全或无”到IND-CCA2:公钥加密安全模型的演进与实战解析
  • 解决‘找不到.so文件’:GCC动态链接库编译成功后运行报错的三种终极解决方案
  • 苏州2026年,探秘苏州灌装机工厂的智造新篇章
  • 简单理解:NFC(近场通信)
  • ESP BLE 安全实战:从配对到加密的代码实现与场景解析
  • 从零到一:手把手教你用conda与pip实现开发环境的无缝迁移与国内源加速
  • 从BUUCTF一道RSA难题看e与φ不互素问题的AMM算法实战解析
  • Unity中Dropdown与TMP_Dropdown的OnValueChange事件优化:解决单选项点击无响应问题
  • 从零到一:基于Keil uVision5与LPC17XX的嵌入式工程构建实战