BACnet楼宇自控开发：C#读写属性、优先级与COV订阅

简介：围绕BACnet楼宇自动控制技术展开的一套C#实践工程，面向准备入门或正在学习BACnet协议、需要动手验证设备读写的开发者，帮助解决协议理解停留在文档层面、缺少可运行示例的问题。压缩包共131个文件，整体约2.12MB，以32个xml配置文件、19个dll程序集、10个pdb调试符号、8个cs源码以及nupkg依赖包、sln与csproj工程文件为主，另含exe可执行程序、png界面截图、txt与config说明，构成可直接编译运行的完整解决方案结构。已有311人学习，说明其在同类学习资料中具备一定参考价值。读者可从中获得设备对象属性读写与属性值变化订阅通知的调用范例，借助源码理清BACnet客户端与设备之间的交互流程，并结合调试符号与依赖包排查运行环境问题，适合作为协议学习阶段的对照代码与二次开发起点。

1. 从一台新风机说起：BACnet 到底在楼里管什么

楼里那台新风机，夏天开多大风、冬天几点关，背后是楼宇自控系统在说话。麻烦在于，一栋楼里的设备来自七八个厂家，控制器、温控器、水表、电表各有各的脾气，谁也不认谁的接口。BACnet 就是让它们能互相听懂的一套通用语言：它规定了设备怎么自我介绍、怎么被读数、怎么被改参数、值变了又怎么主动通知别人。这份资源把 BACnet 楼宇自动控制里最常用的三件事拆成了能跑的 C# 例子——读设备属性、写设备属性、订阅属性值变化。它适合刚接触楼宇自控、会一点点 C# 但没碰过现场设备的人；不适合想研究报文二进制格式的老手。往下读，你会先弄懂几个词，再跑通第一个能读到真实数值的程序。

2. 三个词先记住：对象、属性、实例号

刚打开一份 BACnet 设备手册的人，最常见的反应是「这写的是啥」。满页的 Analog Input、Present_Value、Instance 1001，看着像天书。其实这套模型非常朴素，用一张 Excel 表就能类比完：设备是一张工作簿，对象是里面的工作表，属性是每张表的列，实例号是每张表的编号。把这一层想通，后面所有的读写和订阅，都只是「按编号找到表、按列名取值」的动作。

2.1 一台设备不是「一台机器」，是一堆对象的集合

在 BACnet 的世界里，你连上的那台控制器并不是一个整体，它内部被切成了几十上百个「对象」。一个温度采集通道是一个模拟量输入对象，一个风机启停是一个二进制输出对象，一个季节模式是一个多态输入对象。每种对象类型有自己的名字，比如模拟量输入（Analog Input）、模拟量输出（Analog Output）、二进制输入（Binary Input）、二进制输出（Binary Output）、多态输入（Multi-state Input），以及最特殊的设备对象（Device）。

为什么非要拆成对象？因为拆开之后，所有厂家都遵循同一套描述方式。你不需要知道某台控制器是哪个厂的第几代产品，只要知道它内部有一个「模拟量输入、实例号 3」的对象，就能读到它的当前值。这就是互操作性的来源，也是楼宇自控里跨品牌集成能成立的前提。

这里有个新手最容易忽略的点：对象类型和对象是两回事。Analog Input 是类型，Analog Input 3 才是一个具体的对象。你以后写代码时，几乎每个接口都要同时传「类型」和「实例号」两个参数，少一个都定位不到东西。

2.2 属性是对象的字段，读写读写读的就是它

每个对象身上挂着一组属性，像一张表里的列。以模拟量输入为例，最常用的几个属性是：当前值（Present_Value）、对象名称（Object_Name）、单位（Units）、状态标志（Status_Flags）、报警上下限（High_Limit / Low_Limit）。你打开监控画面看到的那个「23.5 ℃」，本质就是读了一次 Present_Value；你在后台改的那个设定值，本质就是写了一次 Present_Value 或者 Setpoint_Reference。

这里要建立一个很重要的直觉：BACnet 里没有「读一个点」这种说法，只有「读某个对象的某个属性」。这句听起来像抠字眼，但它决定了你写代码时的参数结构。很多新手拿着点名去问设备要值，结果发现接口签名要的是三个参数，卡在那儿半天，就是因为脑子里还停留在「点」的概念上。

还有一类属性叫属性数组，比如 Priority_Array（优先级数组），它本身是一个长度为 16 的数组。读这种属性时要额外带一个数组下标，读到的是某一级优先级上当前挂着什么值。这个后面讲写值的时候会专门说，先记住「有的属性是单个值，有的属性是一串值」。

2.3 实例号是门牌号，别和对象类型搞混

实例号是一个 0 到 4194302 之间的整数，由工程调试人员在设备里配好，作用等同于门牌号。同一台设备内部，同一个类型下的实例号不能重复；不同设备之间，设备对象自己的实例号（也就是设备实例号）在整个网络里必须唯一，这是设备之间互相识别身份的凭据。

我在带新人时见过一种典型翻车：他想读 3 号楼 2 层的温度，从图纸上抄了一个「3」，然后写代码时把对象类型也填成了 3。程序不报错，就是读不到东西，因为类型 3 恰好是模拟量输入，但实例号 3 上挂着的是别的东西。所以每次定位一个对象，脑子里要默念一遍：类型是什么、实例号是多少，两个都要对。

那怎么知道设备里有哪些对象、实例号分别是多少？靠猜是不行的。设备对象上有一个属性叫 Object_List，它列出了这台设备里所有对象的编号。先读它，再挨个读，这是摸清一台陌生设备的标准流程，比翻手册快得多。

2.4 不写代码也能先摸一遍：读和写背后的两个服务

BACnet 把「能做的事」定义成一个个服务（Service）。入门阶段你只需要认识四个：读单个属性（ReadProperty）、一次读多个属性（ReadPropertyMultiple）、写属性（WriteProperty）、订阅变化（SubscribeCOV）。前三个是问答式的，你问一次它答一次；第四个是登记式的，你告诉设备「这个点变了记得喊我」，然后等它主动上报。

在你还没装好开发环境之前，其实可以先用手头工具摸一遍设备，这一步对建立感觉特别有用：

1. 找一台能连上的控制器，确认你的电脑和它在同一个网段；
2. 用厂家自带的调试软件，或者通用的 BACnet 设备浏览器，做一次设备发现（Who-Is 广播，设备回 I-Am）；
3. 在列表里选中那台设备，展开它的对象列表，找到设备对象，读它的 Object_Name 和 Object_List；
4. 从 Object_List 里挑一个模拟量输入，读它的 Present_Value，看看这个数字是不是和现场温度对得上；
5. 找一个允许写的点（比如某个设定值），读一下它的 Priority_Array，看看 16 个格子里哪个有值。

这五步做完，你对「对象 + 属性 + 实例号」的理解会远超看十页文档。而且这一步不涉及任何代码，不会因为环境问题卡住，纯粹是在建立对设备的直觉。等你能熟练地用手点出这些值，再用 C# 复现一遍，速度会快很多。

3. 第一个例子：用 C# 连上设备读一个值

准备工作其实不多，但有几样东西必须先确认，不然代码写得再对也读不到值。这一章的重点不是把 C# 语法讲透，而是让你在最短时间内看到屏幕上打出一个真实的、和现场对得上的数字。那个瞬间对新手很重要，它能把「玄学」变成「工程」。

3.1 动手前的准备清单

先列清楚你需要什么。软件侧：一个能编译 C# 的编辑器，.NET 6 或以上运行时，还有一款 C# 的 BACnet 协议栈库。协议栈库的作用是把底层的报文封装成方法调用，让你不用自己拼二进制。装的时候用包管理器搜一下关键字，选一个还在维护、文档里有示例的就行，具体用哪款不影响你理解后面的内容，因为接口思路都差不多，只是类名不同。

硬件侧：一台能 ping 通的 BACnet 设备，或者厂家提供的模拟器。这点很关键，很多人卡在「没有设备」，其实不少控制器厂商会提供 PC 端的仿真工具，能起一个虚拟设备让你练读写。如果没有，找一个有设备的实验室或同事帮个忙，也比纯看文档强。

信息侧：你需要四样东西——设备的 IP 地址、BACnet 端口（默认 47808，也就是十六进制的 0xBAC0）、目标对象的类型、目标对象的实例号。前两个问网络管理员，后两个从图纸或者设备浏览器里抄。

提示：如果你的电脑和设备不在同一个网段，先解决网络问题再写代码。BACnet 走的是 UDP，很多现场设备不响应跨网段广播，设备发现会失败，但单播读写可能还是通的，这两种情况要分开判断。

3.2 第一个例子的完整代码

先看代码，再逐行解释。下面这个例子的目标是：连上一台设备，读它设备对象的名称和某个模拟量输入的当前值，然后打印出来。

using System; using System.Net; using Bacnet.Client; // 协议栈客户端的命名空间，以你实际引入的库为准 using Bacnet.Core; // 对象类型、属性枚举等基础类型通常在这个命名空间 class Program { static void Main() { // 1. 目标设备地址：现场控制器的 IP + BACnet 标准端口 var deviceIp = IPAddress.Parse("192.168.1.50"); var endpoint = new IPEndPoint(deviceIp, 47808); // 2. 创建客户端。有些库还要在这里传本机端口、超时时间、重试次数 using var client = new BacnetClient(endpoint); // 3. 读设备对象的名字。设备对象的实例号 = 设备实例号 var deviceName = client.ReadProperty( ObjectType.Device, // 对象类型：设备 1001, // 实例号：这台设备的设备实例号 PropertyIdentifier.ObjectName); Console.WriteLine($"设备名称：{deviceName}"); // 4. 读一个模拟量输入的当前值 var presentValue = client.ReadProperty( ObjectType.AnalogInput, // 对象类型：模拟量输入 3, // 实例号：图纸上抄来的 3 PropertyIdentifier.PresentValue); Console.WriteLine($"AI-3 当前值：{presentValue}"); } }

这段代码里真正干活的只有两个 ReadProperty 调用，其余都是准备工作。第一个调用读的是设备名称，它的作用是验证「连接是通的、设备实例号是对的」，因为设备对象一定存在，读它最能排除地址错误。第二个调用才是你真正关心的业务数据，读的是某个模拟量输入的当前值。分两步走是有意为之：一旦第二步失败，你可以立刻判断是对象定位错了，而不是网络问题。

参数逐个说一下。ObjectType 是枚举，常见值有 Device、AnalogInput、AnalogOutput、BinaryInput、BinaryOutput、MultiStateInput，写错类型会读不到东西但通常不报错。实例号是整数，不要写成字符串。PropertyIdentifier 同样是枚举，PresentValue 是最常用的一个，ObjectName、Units、StatusFlags 也经常用。返回值的类型取决于属性，模拟量一般能转成浮点数，对象名称是字符串，读回来之后要按需转换，别一股脑当字符串拼。

3.3 跑不通时先看这三处

新手第一次跑，十有八九不会一次成功。按下面顺序排查，能省很多时间。第一处看网络：能不能 ping 通设备，防火墙有没有拦 UDP 出站，本机是不是有多张网卡导致走错了出口。第二处看身份：设备实例号填的是不是设备的真实实例号，很多控制器面板上写着 Device ID，和对象实例号长得像但含义不同。第三处看超时：默认超时可能只有一两秒，现场设备响应慢的时候会直接抛异常，把超时调到 3 到 5 秒往往就好了。

如果程序没抛异常但打印出来是空值，多半是属性的数据类型处理有问题，比如读回来的值是封装对象，直接打印就成了类型名。这时候把它拆开，看看里面到底是数字还是字符串。这种问题不难，但第一次遇到容易怀疑人生。

3.4 跑通之后马上做的一件事：读 Object_List

第一个值读出来之后，别急着往下写功能。花十分钟把设备的 Object_List 读出来，这一步的价值在于让你知道这台设备里到底有什么。Object_List 是一个数组属性，读法有两种：一次性读全部，或者按下标一个一个读。新手建议先读全部，看看返回了多少个对象，再抽几个挨个读 Present_Value，和现场实际对一对。

这个过程有点像拿到一台新手机先翻一遍设置菜单。翻完之后你对设备的能力边界就有了数：它有几个模拟量输入、几个输出、有没有报警点。后面写监控界面时，你才知道该画多少个格子。顺便说一句，Object_List 里的每个元素是「对象类型 + 实例号」的组合，读的时候要按这个结构解析，不能当成单纯的整数列表。

4. 读写进阶：改一个设定值，再让设备自己上报

能读之后，下一步就是写和订阅。这两个功能是楼宇自控上位机最核心的两块：写用来下发控制指令，订阅用来做实时刷新。这里有一个坎，很多人读写都会了，却卡在「为什么我写了值但设备没反应」，原因就在优先级数组上。

4.1 一次读多个点：批量读省时间

先补一个实用技巧。监控画面上有几十个点，如果一个一个读，一轮下来可能要好几秒，画面刷新会明显卡顿。协议里提供了批量读的服务，一次请求可以带回多个对象的多个属性。C# 里的写法通常是传一个「读请求列表」，返回一个结果集合。

// 构造批量读请求：三个点，每个点读当前值 var requests = new[] { new ReadRequest(ObjectType.AnalogInput, 1, PropertyIdentifier.PresentValue), new ReadRequest(ObjectType.AnalogInput, 2, PropertyIdentifier.PresentValue), new ReadRequest(ObjectType.AnalogOutput, 5, PropertyIdentifier.PresentValue), }; // 一次网络往返，拿回全部结果 var results = client.ReadPropertyMultiple(requests); foreach (var r in results) { Console.WriteLine($"{r.ObjectType}-{r.Instance} = {r.Value}"); }

批量读的参数结构和单点读一样，只是外面套了一层数组。要注意的是，批量读并不是越大越好。有些现场控制器处理能力有限，一次塞几十个请求进去，它会直接不响应或者超时。我的经验是每批控制在 10 到 20 个点，按楼层或者按设备分组，出错时也好定位是哪一组的问题。这个数字不是标准，是现场试出来的，不同厂家差别很大。

4.2 写值为什么有个优先级数组

现在说写。很多人第一次写值的方式是「直接把当前值改成我想要的数」，然后在界面上看到数字变了，就以为成功了。结果过一会儿再读，值又回到原来的样子，或者根本没变。这不是玄学，是优先级在起作用。

BACnet 的输出对象和部分输入对象都有一个 16 格的优先级数组，每一格代表一个优先级，1 最高，16 最低，中间有一个格子是「 relinquish（释放）」。当多个来源同时对同一个点下指令时，谁的数字有效，取决于谁占的优先级更高。比如消防联动写优先级 1，楼控程序写优先级 8，手动操作面板写优先级 16，那么只要消防那一格有值，其他格子的写入都不会体现在当前值上。

所以正确的写法是「占一个格子」，而不是「改一个数」。你写完值之后，读回来的当前值会反映最高的那个非空格子。想撤销自己的指令，就把自己那一格写成释放（null），当前值会自动回落到下一个有值的格子。这个机制在工程上非常有价值，它保证了紧急指令永远压得住日常调节，但对新手来说就是个隐形陷阱：你写的值没生效，不一定是代码错了，很可能是别人占了更高的格子。

上面这张表是行业里的常见习惯，不是协议强制规定，具体项目怎么分配要问清楚。我建议新手统一用 8 或者 16 起步，别去碰 1 到 5，那几个格子通常在调试阶段就被占死了，你抢不到也不该抢。

4.3 第二个例子：写一个设定值再读回来验证

看代码。这个例子的目标是给一个模拟量输出写 21.5，占优先级 8，然后立刻读一次当前值确认生效。

// 1. 写入：占住优先级 8，写入 21.5 client.WriteProperty( ObjectType.AnalogOutput, // 对象类型 5, // 实例号 PropertyIdentifier.PresentValue, // 要写的属性 21.5f, // 写入的值，注意类型要和属性匹配 priority: 8); // 优先级，不传则用默认 // 2. 立刻读回当前值验证 var current = client.ReadProperty( ObjectType.AnalogOutput, 5, PropertyIdentifier.PresentValue); Console.WriteLine($"写后当前值：{current}"); // 3. 用完释放自己那一格，让值回落到其他优先级 client.WriteProperty( ObjectType.AnalogOutput, 5, PropertyIdentifier.PresentValue, null, // null 表示释放这一级 priority: 8);

三步各有各的意义。第一步是真正的写，priority 参数决定了你占哪一格。第二步是验证，注意读回来的可能不是你写的数，如果别人占了更高的优先级，这里就会显示别人的值，这恰恰是排查问题的线索。第三步是释放，很多新手写完就不管了，结果自己的优先级一直占着，别人再怎么调都没用，现场调试的人会被你气死。

写值还有几个要注意的地方。值的数据类型要和对象匹配，模拟量写浮点数，二进制写枚举（比如 0 表示停止、1 表示运行），多态量写整数。写超出量程的值，有些设备会拒绝并返回错误码，有些会直接截断，行为不统一，所以边界检查要自己在代码里做。另外，写操作涉及权限，有些点在生产环境是只读的，写会返回错误，这个错误要捕获并提示，不能让它把程序搞崩。

4.4 订阅属性变化：不用一直问的 COV

前面所有的读，本质都是「你问一次，设备答一次」。监控画面要实时刷新，就得不停地问，这叫轮询。轮询的问题很明显：几十个点每秒问一遍，网络上是持续的请求，设备 CPU 也被你占着，而且大部分时候值根本没变，问了个寂寞。

订阅变化（Change of Value，简称 COV）换了个思路：你告诉设备「这个点我关心，变了记得喊我」，然后就不管了。设备内部自己监测，值变化超过设定的阈值，就主动发一条通知过来。你的程序平时什么都不用做，收到通知再更新界面。网络负载能降一个数量级，实时性反而更好。

这个机制特别适合什么样的点？温度、湿度、压力这种缓慢变化的模拟量，用订阅非常划算。开关状态、报警状态这种偶尔跳变的点，也很合适。反过来，如果你要记录历史曲线、每秒一个采样点，那还是老老实实轮询或者用设备的趋势记录功能，订阅不适合做高频采样。

4.5 第三个例子：订阅一个点并处理回调

代码长这样。目标是订阅一个模拟量输入，值变化时打印出来，订阅有效期设为 300 秒。

// 订阅：告诉设备这个点变了要通知我 client.SubscribeCov( ObjectType.AnalogInput, // 对象类型 3, // 实例号 callback: (objectId, values) => { // 回调里拿到的是变化后的值，不同库的参数结构不同 Console.WriteLine($"对象 {objectId} 变化 -> {values[0]}"); }, subscribeTime: 300, // 订阅有效期，单位秒 issueConfirmedNotifications: true); // 用确认通知，防止丢包

回调函数是整个订阅机制的核心。它不是你去调用的，是设备发通知过来时协议栈帮你触发的，所以回调里面不要做耗时操作，更不要在里面直接操作界面控件，否则很容易卡住或者抛跨线程异常。常见的做法是回调里只把值塞进一个队列或变量，由主线程定时取出来刷新界面。

subscribeTime 这个参数要重点说。它表示这次订阅的有效期，单位是秒，到期后设备就不再通知你了。为什么要有有效期？因为设备不知道你的程序什么时候会崩，如果订阅永久有效，每个连过的客户端都会在设备里留下一条记录，时间长了设备的内存就被占满了。有效期是一种自我保护机制。所以你的程序必须负责续订，在到期之前重新发一次订阅请求。

issueConfirmedNotifications 决定通知要不要对方确认。开了确认，设备发通知后会等你回一个应答，没收到就重发，可靠性高但开销大；不开确认，发一次就完事，丢了就丢了。监控类应用建议开确认，尤其是报警点。

4.6 订阅不是一劳永逸：lifetime 和续订

接着上一段说续订。一个稳定的实现通常是这样的：程序启动时把所有关心的点批量订阅一遍，记下每个订阅的到期时间，起一个定时器，在到期前三分之一的时间点集中续订一次。续订的方式就是再调一次 SubscribeCov，设备会刷新这条记录的有效期。

还有个细节容易被忽略：程序退出时要主动取消订阅。不取消也能活，反正会过期，但在调试阶段反复启动停止，设备里会堆一堆僵尸订阅，占着资源。取消订阅的接口一般是 UnsubscribeCov，参数和订阅时一致。养成「订阅和取消成对出现」的习惯，现场会少很多莫名其妙的故障。

最后提一句阈值。有些设备的订阅支持设一个变化阈值（COV Increment），只有变化幅度超过这个值才通知。比如温度设 0.5，那么从 23.1 变到 23.3 不会通知，变到 23.7 才通知。这个参数设得太小，通知会非常频繁，跟轮询差不多了；设得太大，界面上数字会跳变。一般按工艺要求来，温度 0.2 到 0.5，压力按量程的百分之一左右，具体现场调。

5. 新手避坑：五个最容易翻车的地方

这一章是我带新人时反复听到的抱怨，按出现频率排序。每条都按「现象、原因、解决」写，你可以当成一份急救手册，出问题的时候直接对照。

5.1 能 ping 通却读不到任何值

现象：程序不报错，或者报超时，但电脑 ping 设备是通的。

原因：BACnet 走的是 UDP 47808，ping 走的是 ICMP，两者通路不一样。常见情况是防火墙只放行了 ICMP，没放行 UDP；或者设备只监听了特定网卡，你的包从另一张网卡出去了；还有一种情况是设备配置了 BBMD（广播管理设备），跨网段时需要专门配置才能通信。

解决：先确认防火墙对 UDP 47808 的出入站都放行，再确认本机路由走的是哪张网卡（多网卡机器尤其容易出错），最后确认是否跨网段以及有没有 BBMD。这三步按顺序查，不要跳。

5.2 实例号抄错，或者类型和实例号搞反

现象：读某个点一直读不到，换成别的点又能读到。

原因：把对象类型当成了实例号，或者从图纸上抄错了数字。还有一种情况是不同楼层的图纸用的是同一套编号，实际设备里加了偏移，比如 2 层的 3 号点实际是 103。

解决：先读设备的 Object_List，把真实存在的对象列出来，和图纸对一遍。这一步能解决九成的定位错误。对不上就以设备里的为准，图纸只是参考。

5.3 写了值但读回来还是原来的数

现象：WriteProperty 没报错，但紧接着读当前值，数字没变。

原因：优先级被人占了。你写的是 16 级，而楼控程序在 8 级上一直有输出，当前值就永远显示 8 级的数。还有一种可能是你写的属性和设备实际使用的属性不是同一个，比如你写 Present_Value，但设备逻辑读的是 Setpoint_Reference。

解决：先读 Priority_Array，看看 16 个格子里哪些有值、值是多少，一眼就能看出谁在压着你。再确认这个点到底该写哪个属性，有些点的设定值和当前值是分开的两个属性，写错了当然没反应。

5.4 订阅了几分钟就收不到通知了

现象：刚订阅上的时候能收到变化，过一段时间彻底没动静，重新订阅又好了。

原因：订阅有有效期，到期自动失效。你的程序没有续订逻辑，或者续订定时器被异常打断了。

解决：给每个订阅记录到期时间，起一个定时器在到期前续订。同时加上日志，把订阅成功、续订、失效都打出来，出问题时一眼能看出是没续上还是设备那边掉了。

5.5 点一多就大面积超时

现象：单点测试都正常，接上几十个点之后，程序开始随机超时，设备响应也变慢。

原因：请求发得太密，或者批量读一次塞了太多对象，超出了设备的处理能力。有些低端控制器每秒只能处理个位数的请求，你一下子发几十个，它只能丢包。

解决：控制并发，串行发送或者限制同时未完成的请求数；批量读按 10 到 20 个一组分批；给每个请求设合理的超时和重试次数，重试不要无限循环。还有一个容易忽略的点：轮询间隔不要太短，能订阅的点尽量用订阅，别用轮询硬刷。

6. 下一步学什么：从能读能写到能做界面

走到这里，你已经能连设备、读属性、写值、订阅变化了。这四件事组合起来，其实已经够做一个最小可用的监控小工具。接下来往哪走，取决于你想做哪一层的工作。下面这条路线是我带新人时常用的顺序，按它走不会绕远。

第一步的重点不是写代码，是把对象模型刻进脑子里。拿到任何一台设备，先读 Object_List，再按类型分组，看看它有哪些输入输出。这个动作做熟了，后面看任何厂家的设备都不会发怵。

第二步是分水岭。很多人写的代码只能在实验室跑，一到现场就崩，问题几乎都出在异常处理上。现场设备会掉线、会重启、会返回各种错误码，你的代码必须扛得住。建议的做法是给每个请求包一层统一的方法，把超时、重试、日志都收在里面，业务代码只关心结果。

第三步和第四步是工程能力的体现。优先级管理做不好，现场调试的人会天天找你；订阅续订做不好，界面上的数会莫名其妙停住不动。这两块没有捷径，多写几遍就有感觉了。

第五步往上就是架构层面的事了。别把设备读数直接绑到界面控件上，中间一定要有一层缓存模型，界面定时从缓存取数。这样做的好处是设备掉线时界面显示的是最后一次有效值加一个离线标记，而不是一片空白或者直接崩掉。这个习惯越早养成越好。

如果你还想再深入，可以去看协议里的服务端部分，也就是自己做一个设备或者网关，让别的系统来读你。这一步会逼着你把所有细节都想清楚，是检验理解程度的好办法。另外，对象类型里的日程（Schedule）、趋势记录（Trend Log）、通知类（Notification Class）这几个高级对象，实际项目里用得不少，可以挑一个感兴趣的单独研究。

我第一次做这类项目的时候，图省事把所有读取都写成了单点轮询，界面上一百多个点，每秒刷一遍。实验室里跑得好好的，到了现场第二天就开始大面积超时，设备直接被拖慢，现场调试的人打电话过来问是不是我的程序在捣乱。从那以后我每次接手新设备，都会强制走一遍「先读 Object_List 摸清家底、再按分组批量读、能订阅的绝不轮询」这个流程，再也没翻过同样的车。你刚开始学的时候可能会觉得这些规矩麻烦，等真的在现场跑起来，就知道省下的是自己的时间。希望帮到你。

本文还有配套的精品资源，点击获取