预付费电表的工作原理是什么

预付费电表很多人理解错了——以为是把钱充进电表里面，跟投币洗衣机一个逻辑。实际上完全不是这么回事。预付费电表的核心是系统钱包，用户充值充的是平台账户，电表只负责计量用电量并上报，系统端根据用量从钱包扣钱。搞混了这个架构，充值不到账、欠费不断电这些"故障"就不是电表的锅，是整个充值-计量-扣费链路没搭对。

一、钱存在哪：系统钱包不是电表钱包

用户充值——不管是通过微信小程序、支付宝、还是物业前台缴费——钱进的是后台管理系统的用户账户钱包，不是进电表。电表本身不具备金额存储能力，它的任务就三个：计量用电量、把数据上报给系统、接收并执行系统的拉合闸指令。

这一点对集成商做方案很关键。如果客户说"电表里充了钱怎么还跳闸"，你得解释清楚：电表不存钱，跳闸是系统检测到钱包余额不足自动下的拉闸指令。IC卡方案是唯一例外——老式IC卡电表确实在电表内部设了一个余额寄存器，通过物理插卡方式同步金额。但2026年的新项目基本淘汰了这个方案，都走远程充值+系统钱包模式。采购选型的时候别买IC卡方案的电表，运维成本太高。

二、计量和扣费怎么配合的

预付费电表做的事：实时采集电压电流数据，算出用电量，按设定的上报周期（一般是15分钟或1小时）把电量数据发给后台系统。这个数据通过RS485、4G或NB-IoT通信传上去，电表本身不执行扣费逻辑。

系统做的事：收到电量数据后，按当前电价（阶梯电价、峰谷电价或固定电价）乘以用电量，从用户钱包余额里扣除对应金额。比如电价0.6元/度，这15分钟用了3度电，系统扣1.8元。这个扣费是系统端的SQL事务，跟电表没关系。电价参数也配在系统后台，不是配在电表里——系统改电价影响所有用户即时生效，不需要逐块表下发参数。

三、欠费怎么断电的

系统端持续监控用户钱包余额。余额降到报警阈值（比如10元），系统推送短信或微信通知给用户。余额降到零或负值，系统自动生成一条拉闸指令，通过通信链路下发到对应电表。电表收到拉闸指令后驱动内置磁保持继电器断开供电回路，断电完成。确认信号回传系统，系统标记该用户为"欠费断电"状态。

这才是完整的欠费断电链路：系统判断余额→生成指令→通信下发→电表执行继电器动作→回传确认。任何一环断了都会导致欠费不断电。常见断点：通信掉线导致指令发不出去，或者继电器触点粘连导致指令执行了但实际没断开。运维排查的时候按这个链路逐环定位，别上来就换电表。

四、充值后怎么恢复供电

用户充值——钱进系统钱包，余额从负变正。系统检测到余额恢复后，自动生成合闸指令下发到电表。电表收到指令驱动继电器合闸，恢复供电，回传确认。整个过程从充值到送电通常在5秒内完成。

"充了值但不送电"是最高频的投诉，排查优先级：第一，通信链路是否正常——系统发了指令但电表没收到，查4G信号或RS485总线状态；第二，系统策略是否配了"欠费后延迟充值生效"（有些物业设了欠费后即使充值也要人工审批才送电）；第三，继电器是否故障。集成商部署的时候建议在后台加一个"手动远程合闸"功能按钮，作为自动合闸失败时的兜底手段，接到投诉不用跑现场。

选型抓住核心：买的是电表+通信+系统平台三件套，不是单独一块表。预付费电表负责计量和拉合闸，通信负责数据传输，系统负责钱包管理和扣费逻辑。三者缺一不可。部署阶段重点检查通信在线率和系统扣费策略配置，这两个是预付费方案的主要翻车点。