本文内容
采购 LoRaWAN 水表前，如何现场验证读数和漏水报警？
现场人员可以读出表盘上的数字，值班员到下一次定时上报时就能在系统里核对同一笔读数。漏水报警怎么核对？得先弄清楚这款水表在什么条件下判定漏水、什么时候上报，以及值班员收到报警后能否找到对应的安装点。批量下单前，我会请供应商用同一台样表演示抄表和报警这两项功能。
因斯布鲁克的现场测试是怎么做的？
我们参与时，因斯布鲁克市政公用事业公司（IKB）已经在主导这个项目。有些水表原先支持车辆经过时抄读，但工作人员仍要开车走一趟。IKB 希望利用全市的 LoRaWAN 网络减少抄表出车，让运行人员更早拿到新读数。在IKB 发布的一篇访谈中，电信团队的一位员工谈到，报警曾帮助他们及早处理用户尚未察觉的漏水。
我们在一个常见的安装位置测试水表，又选了一个预计无线信号较弱的位置做对照。项目还涉及其他设备，包括货运自行车定位器。我们和 IKB 团队一起开发看板，供运行人员排查异常。有些报文会定时发送，有些要等特定事件发生才出现。不少设备发来的报文与手册相符。也有少数设备，只有把实际收到的报文与手册逐项比对，才能看出差异。我们把真实报文保存下来，之后就可以离线反复解码。IKB 项目案例记录了这部分工作。
批量采购前，应请供应商现场演示什么？
做验收时，我会请运行团队选两个有代表性的安装点，一个是常规点位，另一个是接收条件较差的点位。两处都使用计划投运时的设备配置。请供应商说明抄表数据多久上报一次、水表在什么情况下判定漏水，以及何时发出报警。供水单位还要明确允许读数滞后多久，以及值班人员最迟应在什么时候收到报警。
| 项目 | 怎么测 | 验收记录 |
|---|---|---|
| 抄表 | 记下某一测量时刻的表盘读数，在看板上找到对应记录。按约定的上报周期，在两处分别重复观察。 | 记录表号、两端的数值及单位、测量时间和接收时间。单独标出应到而未到的报文。 |
| 漏水报警 | 在样表或试验台上按厂家规定的测试流程触发报警。请值班人员通过约定的渠道接收。 | 记录触发和接收时间、表号及报警状态。请值班人员指出需要到哪个安装点处置。 |
| 恢复正常 | 结束测试，按设备说明观察报警如何解除。 | 记录看板何时恢复、最终显示什么状态。若报警仍然有效，注明由谁跟进。 |
有的测试模式会直接发出报文，跳过传感器本身的检测过程。这种演示可以验证报警从水表发出后能否送达。若还要验证水表能否识别漏水，需另行与厂家确认相应的台架试验。
看板没有报警，从哪里查起？
先确认报文什么时候该到。有的水表会把漏水状态放在下一条定时报文里。弄清预计上报时间后，再看应用是否在那段时间收到过这台水表的报文。IKB 对其 LoRaWAN 网络的介绍说明了传感器与网关在传输中各自的作用。
如果报文已到，就逐项核对三件事：设备手册怎样定义该字段、样表当时处于什么状态、解码器实际给出了什么值。The Things Stack 的报文解析文档说明了怎样把传输的字节转换为可读字段。用我们的 LoRaWAN 编解码测试工具可以反复解读同一条已保存的报文，修改程序后无需等待设备再次报警就能核对结果。要确认安装点的无线接收情况，仍需回到现场测试。
拿到什么结果可以下单？
让采购人员能按点位查到三项记录：预计收到多少次读数、实际收到多少次，以及值班员是否在约定时间内识别出报警并找到对应安装点。如果两处都收到了读数，但只有一处成功上报报警，就把另一处的报警列为待复测项。如果补救办法是增设网关，接受报价前要先确认站点安装许可和日后维护的通行条件。
如果还在选择通信方式，可以参考我们的 LoRaWAN、NB-IoT 和 Sigfox 试点成本比较。选定网络后，再按试点范围规划指南约定采购前需要验证哪些事项。若要和我们的市政物联网工程团队一起安排现场测试，可以先准备一台样表、设备手册和两个候选点位。