8.3 KiB
title, aliases, tags, audience, status, sub_feature, last_review, code_version
| title | aliases | tags | audience | status | sub_feature | last_review | code_version | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · meter · 场景 - 集抄系统自动推送(source=remote) |
|
|
|
已发布 | meter | 2026-05-26 | 2026-05-22 |
场景:集抄系统自动推送(source=remote)
集抄系统(IoT)通过 RS485 / NB-IoT / LoRa 等技术远程读取物理表读数,定时(每天 / 每小时 / 每月)推送给本系统。本系统收到后建 MeterReading(source=remote),完全自动,无人工介入。是现代化物业的标配。
典型情境
[!example] 真实情境 嘉禾花园 2 年前升级了集抄系统,1,200 张水电气表全部接入 IoT 网关。集抄运营商每月 1 日凌晨统一上传上月用量数据到本系统。
物业财务王主管早上来上班,集抄数据已经全部到位 + 账单已经自动生成。她只需要:
- 看 dashboard 异常告警(高用量 / 集抄掉线表)
- 手工处理少数异常情况
系统流程
sequenceDiagram
participant Meter[物理表]
participant Gateway[IoT 网关]
participant Vendor[集抄运营商平台]
participant API[本系统集抄 API]
participant 数据库
participant GenerateBills
Note over Meter: 物理表每月 1 日凌晨自报
Meter->>Gateway: 读数推送(RS485 / NB-IoT)
Gateway->>Vendor: 上传(GSM / 4G / 有线)
Vendor->>Vendor: 整合 + 校验 + 归档
Note over Vendor: 月度批量推送(可能是每天 / 每月)
Vendor->>API: HTTP POST(批量推 readings)
API->>API: 校验签名 + 防重放
API->>API: 校验 meter 是否存在 + 是否 active
loop 每条 reading
API->>数据库: 建 MeterReading(source=remote, operated_by=null, photo_url=null)
end
API->>GenerateBills: handle(刚建的 readings)
GenerateBills->>数据库: 批量建 Bill + 回写 reading.bill_id
API-->>Vendor: 响应(成功 N,失败 M)
业务人员视角
日常(集抄正常运行)
业务人员几乎不操作:
- 看
MeterDashboard(自动跳出异常告警) - 月度对账(
audit-meters-needing-reading.md类似审计) - 不需要手动抄表 / 录入
月初(集抄推数完成后)
通常上午到岗时:
- 所有 reading 已经在
MeterReading表里 - 所有 Bill 已经生成
- Dashboard 显示:本月已抄 N 张 / 应抄 M 张
- 看
HighConsumptionReadingsListWidget异常告警 → 处理(exception-high-consumption) - 看
MetersNeedingReadingListWidget显示掉线 / 漏抄表(本场景的兜底:走 read-single-meter-manual 个别补抄)
异常(集抄掉线)
| 掉线规模 | 处置 |
|---|---|
| 个别表(< 5%) | 抄表员补抄(read-single-meter-manual) |
| 大面积(网关故障) | 联系集抄运营商修复 + 物业短期手抄兜底 |
| 长期掉线(> 2 周) | 重新评估集抄设备的可靠性 |
集抄 API 设计(待文档化 / 实现细节)
[!info] 当前实施状态 集抄 API 的具体实现细节(endpoint、签名、数据格式、防重放)需要看代码或与集抄运营商对接文档,本场景描述业务流程层。
接口要求
| 要求 | 说明 |
|---|---|
| 接收端 | 本系统提供 HTTP POST endpoint |
| 数据格式 | JSON 数组,每条 reading 字段:meter_code / read_at / current_reading / community_id / vendor_signature |
| 签名校验 | 防伪造,通常 HMAC-SHA256 或非对称签名 |
| 防重放 | 同 meter + 同 read_at 不重复建(unique index) |
| 错误响应 | 详细告知哪条失败、原因 |
| 失败重试 | 集抄运营商按响应决定重试逻辑 |
MeterReading 字段对照
集抄推送的 reading,数据库存的 MeterReading:
| 字段 | 集抄数据 | 系统存 |
|---|---|---|
meter_id |
集抄推 meter_code → 系统查 | meter ID |
read_at |
集抄推时间(通常表自身上报) | datetime |
current_reading |
物理表读数 | decimal(12,2) |
previous_reading |
(系统自动取上次) | decimal |
consumption |
(系统自动算) | decimal |
source |
(系统设) | remote |
operated_by |
null(集抄无人) | null |
photo_url |
null(集抄无照片) | null |
bill_id |
null(初始)→ 后续 GenerateBills 回写 | 可空 |
memo |
选填(集抄可能写型号 / 网关 ID) | text |
集抄 vs 手抄 数据差异
| 维度 | manual(手抄) | remote(集抄) |
|---|---|---|
| 录入速度 | 慢(几天到几周) | 几小时全社区 |
| 准确性 | 中(手抖 / 看错) | 高(机器直读) |
| 拍照存证 | 强烈推荐 | 无(IoT 设备自身就是凭证) |
| operated_by | 抄表员 ID | null |
| 业户感知 | 抄表员上门 | 无感(无人上门) |
| 异常处理 | 抄表员现场判断 | 系统后台告警 → 人工介入 |
| 成本 | 抄表员工资 | IoT 设备 + 网关 + 月度服务费 |
| 业户家在不在影响 | 影响(开门才能抄) | 无影响 |
业户视角
业户完全无感 —— 集抄系统的存在业户可能都不知道(除非物业告知)。
唯一感知:
- 账单出来更准时(每月固定日期到账)
- 没人上门抄表(隐私感更好)
- 用量明细可能更详细(集抄能支持小时 / 天级别 granularity,虽然账单仍是月度)
集抄设备与本系统的关系
flowchart TB
subgraph "物理层"
M1[家用水表]
M2[家用电表]
M3[工业表]
end
subgraph "网关层"
G1[楼栋网关<br/>RS485 → 4G]
end
subgraph "运营商层(第三方)"
V[集抄运营商平台<br/>设备管理 / 数据归档 / API 输出]
end
subgraph "本系统(prop-acc)"
API[集抄 API endpoint]
DB[(MeterReading)]
GenerateBills[GenerateBillsFromMeterReadingsAction]
Bill[(Bill)]
end
M1 --> G1
M2 --> G1
M3 --> G1
G1 --> V
V -->|每月推送| API
API --> DB
DB --> GenerateBills
GenerateBills --> Bill
本系统只管接收 + 存 + 生成账单。不管物理设备、网关、信号质量。这些都是集抄运营商的事。
常见问题
[!question] 集抄数据准确吗?会不会比手抄更容易出错? 集抄数据理论上更准(机器直读,没手抖)。但:
- IoT 设备本身可能故障(读数漂移、传输错)
- 信号不好可能漏传(掉线)
- 集抄运营商平台可能 bug(数据传错)
准确性强烈依赖集抄运营商的可靠性。选大牌运营商 + 完善 SLA。
[!question] 集抄推过来的数据能改吗? 不能(MeterReading 不可变,见 decommission-and-locking)。如果集抄推错:
- 在系统侧建错误 reading
- 走作废 Bill → 删 reading(若 Policy 允许)→ 集抄重推
- 或运维 tinker 介入
[!question] 集抄运营商收费贵不贵? 看市场,通常:
- 设备 + 安装一次性几十到几百每点
- 月度服务费 几元 / 表 / 月
中型社区(1,000 表)月度成本可能几千到几万。物业自行评估"省抄表员工资 vs 集抄费用" ROI。
[!question] 集抄系统对接需要多久? 看运营商:
- 大牌(华为 / 海康)平台标准 API → 1-2 周(主要是数据格式映射 + 测试)
- 小厂自研协议 → 1-3 个月(需自定义对接代码)
[!question] 集抄推数据时本系统有问题(数据库挂 / 网络断)? 集抄运营商应有重试机制(看 SLA)。本系统应:
- API 幂等(同 meter + 同 read_at 不重复建)
- 失败响应详细(让运营商知道哪条没收到)
- 重要数据有补传机制(运营商手动重推)
[!question] 集抄数据与业户预存款自动扣的关系? 集抄推数 → 生成 Bill → 触发 [../prepaid/auto-deduction-design|预存款自动抵扣 job]→ 业户预存款余额自动扣 + Bill 翻 Paid。
整条链完全无人介入,业户次日推送:"5 月电费 ¥168 已自动扣,余额 ¥X"。
异常分支
- 集抄掉线个别表 → read-single-meter-manual 兜底
- 集抄数据异常用量 → exception-high-consumption
- 集抄推错数据需修正 → exception-readings-locked-after-bill
- 集抄 API 故障 → 运维 / 集抄运营商支持