247 lines
8.3 KiB
Markdown
247 lines
8.3 KiB
Markdown
|
---
|
||
|
|
title: prop-acc · meter · 场景 - 集抄系统自动推送(source=remote)
|
||
|
|
aliases:
|
||
|
|
- 集抄系统
|
||
|
|
- IoT 抄表
|
||
|
|
- read-via-iot-remote-source
|
||
|
|
- 场景-集抄自动抄表
|
||
|
|
tags:
|
||
|
|
- 场景
|
||
|
|
- prop-acc
|
||
|
|
- 计量表
|
||
|
|
- 抄表
|
||
|
|
- IoT
|
||
|
|
audience:
|
||
|
|
- 业务人员
|
||
|
|
- 架构师
|
||
|
|
- 抄表员
|
||
|
|
status: 已发布
|
||
|
|
sub_feature: meter
|
||
|
|
last_review: 2026-05-26
|
||
|
|
code_version: 2026-05-22
|
||
|
|
---
|
||
|
|
|
||
|
|
# 场景:集抄系统自动推送(source=remote)
|
||
|
|
|
||
|
|
集抄系统(IoT)通过 RS485 / NB-IoT / LoRa 等技术**远程读取**物理表读数,定时(每天 / 每小时 / 每月)推送给本系统。本系统收到后建 `MeterReading(source=remote)`,**完全自动,无人工介入**。是现代化物业的标配。
|
||
|
|
|
||
|
|
## 典型情境
|
||
|
|
|
||
|
|
> [!example] 真实情境
|
||
|
|
> 嘉禾花园 2 年前升级了集抄系统,1,200 张水电气表全部接入 IoT 网关。集抄运营商每月 1 日凌晨**统一上传上月用量数据**到本系统。
|
||
|
|
>
|
||
|
|
> 物业财务王主管早上来上班,集抄数据已经全部到位 + 账单已经自动生成。她只需要:
|
||
|
|
> - 看 dashboard 异常告警(高用量 / 集抄掉线表)
|
||
|
|
> - 手工处理少数异常情况
|
||
|
|
|
||
|
|
## 系统流程
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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,虽然账单仍是月度)
|
||
|
|
|
||
|
|
## 集抄设备与本系统的关系
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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 故障 → 运维 / 集抄运营商支持
|
||
|
|
|
||
|
|
## 相关文档
|
||
|
|
|
||
|
|
- [[meter-vs-meter-reading]]
|
||
|
|
- [[reading-source-and-photo-proof]]
|
||
|
|
- [[bill-generation-pipeline]]
|
||
|
|
- [[read-single-meter-manual]]
|
||
|
|
- [[read-batch-via-excel-import]]
|
||
|
|
- [[exception-high-consumption]]
|