BACnet Status_Flags 的位串怎么读：为什么不能按整数最低位拆

BACnet BitString 的第一个内容字节声明末字节未使用的位数，随后位串按每字节最高位先取。StatusFlags有四个有定义的位，不能把内容字节按普通整数最低位开始拆，也不能忘记尾部填充。

适用版本与输入范围

依据维护者 bacnet-stack 固定标签 bacnet-stack-1.4.0 的下列源码解释公开实现子集。该参考不是 ASHRAE 标准全文；涉及具体楼控设备时仍需记录型号、固件和对象支持范围。 本文所有输入均为原创合成数据，未接真实设备。

先读unused-bits再求有效位数

输入04 90中，04不是状态值，而是末尾四位未使用；90的高四位1001才是有效状态。程序计算有效位数为内容字节数乘八再减unused，得到四位。第二条九位通用位串用07 A5 80，两个数据字节只有九位有效，适合验证跨字节与尾部数量。首字节unused必须在0到7之间，不能直接当成有效位数使用，否则四位案例可能凑巧正确，九位案例就暴露错误。

状态编号从最高位依次对应

StatusFlags四位按顺序对应in_alarm、fault、overridden、out_of_service，因此1001表示报警与退出服务为真，中间两个为假。程序保留bits原序列，再在明确声明status_flags=true时添加名字；通用九位输入不强行套四个标志。位串语义由属性定义决定，不能见到四位就自动断定是StatusFlags，抓包提取仍需结合对象和属性上下文。

长度正确仍要检查尾部内容

显式负例04 91与正例有效四位完全一样，但最后低四位包含一个非零位，程序报告填充非零。另一条00 90表示八位全有效，却声明要解成StatusFlags，必须拒绝位数不符。这样可以分开验证通用BitString结构和特定属性宽度。静默丢掉多余位会让日志看起来正常，却失去发现编码器缺陷的机会；保存原始hex有助于定位到底是提取边界还是发送端问题。

质量标志不等于控制联锁

解析fault或out_of_service为真，只说明给定属性编码包含对应状态，并不直接证明设备已经停机或某个安全功能生效。状态解释应与对象规范、厂商手册及现场流程对应，不能只凭一位自动触发未经确认的动作。此次程序只读取合成字节，不查询楼控系统、不改变属性。工程交付建议把四个标志分列保存，同时保留原始BitString和数据时间，避免归并成一个模糊的“异常”而丢失具体原因。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 4 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。bits按BACnet位编号排列；flags仅在明确声明StatusFlags且有效四位时生成。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到BACnet 对象与服务入门核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• encode_application_bitstring / decode_bitstring
• StatusFlags 四状态枚举（bacenum.h）

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。