文章开篇就点出一个真相：建筑的各个子系统之间缺乏融合，这是智能建筑发展的最大障碍。空调是空调、照明是照明、安防是安防，每个系统由不同的施工单位负责、用不同厂家的设备、跑在不同的协议上。结果就是一栋楼里有好几个互不干扰的"独立王国"。
这种状况怎么形成的？说到底还是行业的习惯。做暖通的只管暖通，做弱电的只管弱电，做网络的只管网络。项目招标的时候也是分包的——暖通一标段、弱电一标段、智能化又一标段。各干各的，最后集成的时候才发现"合不拢"。
文章里提到一个概念叫"convergence"（融合），意思是把所有的建筑系统整合到一个统一的IP网络上。这个思路我特别认同。IP网络是现成的，成本低、扩展性好。以前BAS走的是RS485总线，照明走的是DALI总线，安防走的是同轴电缆。现在全部换成IP网络——摄像头走IP，楼宇控制器也走IP，甚至传感器都可以走IP。
融合需要标准。文章重点推荐了BACnet和MQTT两个协议。BACnet是老牌的楼宇自控协议，在暖通领域统治了20多年，成熟稳定。MQTT是物联网时代的轻量级协议，适合传感器数据传输。两个协议各有优势，可以互补使用。
但文章也指出一个问题：很多设备厂商嘴上说支持开放协议，实际上在实现上做了手脚——不是完全兼容的。你用A厂商的BACnet控制器去接B厂商的空调，可能有些功能就是用不了。所以文章建议在采购时明确要求"第三方互操作性测试"的证明。这个我太有体会了——"支持BACnet"和"通过BACnet互操作性测试"根本是两码事。
REST API也是一个趋势。现代的智能建筑平台越来越倾向于用Web API来对接各个子系统。REST API的好处是简单、灵活，任何一个程序员都能调用。但问题是很多传统设备厂商对API不够开放，或者API文档写得一塌糊涂。
文章最后提出了一个"分步融合"的策略：先做数据层面的融合（把各个系统的数据集中到一个平台），再做控制层面的融合（通过平台统一控制各个子系统），最后做决策层面的融合（基于全楼数据做智能化决策）。这个路线图很务实，不是一口吃成胖子。
我的看法是：融合之路注定不会一蹴而就，但方向是对的。我们国内的项目也一样。如果你正在做一个智能建筑项目，多花点精力在系统集成和数据打通上，比单方面追求某个设备的先进性更有长期价值。