MQTT智能通断器GSCW1M2P · 开发者实战指南

GemeOpen GSCW1M2P 智能通断器（25A） · 开发者实战指南

面向软件开发者、集成商项目经理、传统电子设备厂的深度应用手册

从「为什么 10A 插座不够用」到「怎么落地赚钱」——涵盖协议、写代码、调试、大功率用电采集、安装施工、与传统配电/工业系统对接、24 个应用场景、成本收益与运维体系。

目录

• 第 1 章 开篇：当 10A 插座不够用——25A 通断器的战场
• 第 2 章 认识 GSCW1M2P：25A/6000W、接线式、用电采集与能力边界
• 第 3 章 协议与指令全景
• 第 4 章 快速上手：15 分钟控制一台大功率设备（三语言）
• 第 5 章 大功率用电采集与计量
• 第 6 章 调试手册：从"没反应"到"一眼定位"
• 第 7 章 二次开发进阶：把它变成你的产品
• 第 8 章 云平台对接与系统集成
• 第 9 章 与传统电气设备对接
• 第 10 章 自动化与安全用电：让大功率设备"听话且安全"
• 第 11 章 安装与施工：25A 是"电工活"
• 第 12 章 与配电系统/工业设备对接
• 第 13 章 应用场景 12 例
• 第 14 章 应用场景 12 例（编号 13~24）
• 第 15 章 省钱账：一个通断器帮你省了什么
• 第 16 章 增效：自动化带来的收益
• 第 17 章 增收：把通断器变成商业模式
• 第 18 章 项目管理：集成商视角的落地方法论
• 第 19 章 运维体系：让系统长期稳定
• 第 20 章 附录
• 附录 A · 设备规格与指令基准

第 1 章 开篇：当 10A 插座不够用——25A 通断器的战场

一句话点题：智能插座能管住台灯和风扇，却管不住空调和热水器；GSCW1M2P 这类"接线式大功率通断器"，正是为了接管那些 10A 插座不敢碰的负载而生。

1.1 三个真实痛点

大部分人第一次接触"智能插座"，都是从几十块一个的插头式产品开始的：插上去、连 WiFi、手机点一下，台灯就亮了，确实很爽。但只要你手里的设备稍微"重"一点，这套逻辑立刻就绷不住了。下面三个场景，几乎每周都会以工单的形式出现在集成商和方案商的群里。

痛点一：大功率设备根本插不进去。
家用挂机空调普遍 1.5 匹到 3 匹，运行功率一两千瓦起步，压缩机启动那一下更是额定值的数倍；储水式电热水器动辄 2000W~3000W；即热式热水器甚至能到 7000W 以上。普通插头式智能插座标称 10A、约 2200W，遇到这类设备要么直接"带不动"跳闸，要么长期在临界点工作、插座发烫、继电器粘连、塑料壳体变形——这就是火灾隐患。用户想的是"让空调能远程开"，结果面对的是"插座根本扛不住"。

痛点二：想手动开关，纯属浪费时间和人力。
办公室的前台、门店的招牌灯、工地临时用电、民宿的泳池循环泵——这些设备常常需要"下班断电、上班通电"。如果没有自动化，就得每天专程跑一趟人工拉闸；如果装的是普通智能插座，又要面对"功率不够、回路不匹配"的问题。时间一长，没人愿意干这件事，于是设备常年通电，白白耗电还加速老化。

痛点三：能耗是个黑盒，电费说不清。
一个充电桩旁的商用冰柜、一排共享洗衣机、几台小型电机，每月电费到底花在谁身上？传统方式是装一个独立的电表，成本高、布线麻烦、还得人工抄表。谁都想要一个"既能远程开关、又能顺带上报用了多少电"的东西，把"控制"和"计量"合二为一。

这三个痛点的共同解，就是 接线式大功率智能通断器。它不做"插头"，而是像开关一样串进线路里，用 25A / 最大 6000W 的能力去接管大负载，同时把电压、电流、功率、用电量一路采集并上报。GemeOpen GSCW1M2P（产品名"智能通断器 25A-S2 Plus-WiFi"）就是这一类的典型代表。

1.2 插座 vs 通断器的分工

很多人会把"智能插座"和"智能通断器"混为一谈，其实它们是两种定位完全不同的产品。打个比方：智能插座像"插座上的开关"，只能管那些已经用插头插上的电器；而智能通断器像"配电箱里的一路空气开关"，它本身就是线路的一部分，想控制哪条回路，就把哪条回路接到它身上。

一句话总结分工：10A 插座负责"轻量、随手"，25A 通断器负责"重载、工程"。当你的设备功率超过 2000W，或者根本没有插头（是接到线路上的），桌面上的路就已经走死了，唯一的正解就是接线式通断器。

1.3 这份文档写给谁，怎么读

这篇文档不是"开箱即用"的说明书，而是一份面向开发者的技术开发指南。它假设你已经有能力读懂代码、看懂接线图、或者至少能把它讲给电工听。根据你的身份，建议这样读：

• 软件开发者：重点在第 3 章（协议与指令全景）和第 4 章（三语言快速上手）。你要关心的是用什么协议、发什么字段、收到什么响应、数据在哪。
• 集成商 / 项目经理：重点在第 2 章（能力边界、寿命预算）和第 4 章的落地清单。你要关心的是"能不能扛住这个负载"“多少个点”“验收怎么过”“会不会有隐性成本”。
• 传统电子设备厂 / 硬件工程师：重点在第 2 章（电气规格、接线约束、寿命）和每章末尾的工程提示。你要关心的是线径、空开、降额、散热与可靠性。

无论你属于哪一类，请记住全文有一条贯穿始终的红线：这是强电设备，涉及 110~260Vac 市电，任何接线作业都必须断电进行、由专业电工操作，并配备足够容量的空气开关 / 漏电保护器。

本章要点

第 2 章 认识 GSCW1M2P：25A/6000W、接线式、用电采集与能力边界

一句话点题：要把一台设备用对、用好，先得把它"能做什么、不能做什么"看得明明白白——本章逐条拆解 GSCW1M2P 的规格、寿命与能力边界，尤其把"视在功率"这个最容易踩坑的概念讲透。

2.1 规格逐条解读

先看规格表，再逐条解释它对你意味着什么。

逐条说人话：

• ESP8266：这是被海量物联网产品验证过的主控，意味着资料多、轮子全、出问题好排查。对二次开发友好，你几乎不用担心"芯片太冷门找不到资料"。
• 50×110×32mm：大致是一包香烟的体量，接线式产品里算紧凑。安装时要预留进出线空间和散热间隙，别把线挤死。
• 110~260Vac 宽压输入：这一条很重要，它决定了设备的市场适配性——同一个型号能覆盖国内 220V 与海外 110V 场景，出口项目不用另配型。
• 单路输出：再次强调，它是一路通断器。要实现"三台设备分开控制"，就得用三个，而不是幻想一个设备管三路。
• 25A / MAX 6000W（阻性）：25A × 220V ≈ 5500W，标注 MAX 6000W 是阻性负载峰值能力。"阻性"两个字是本章后面 2.3 节的重点。
• 待机 < 4W：设备自身长期通电的损耗很低，做常年在线控制不会有"设备自己就很耗电"的尴尬。
• MQTT / TCP / HTTP：控制协议三选一（或组合），这是它"面向开发者"的核心卖点。
• V0 级阻燃外壳：万一内部异常发热，外壳不易助燃，这是电气安全的基本盘。

重要提示：本型号无 RS-485、无红外遥控。如果你的方案里原本规划了"接 485 总线"或"用红外遥控空调"，请改设计——这里只有 WiFi + MQTT/TCP/HTTP。

2.2 寿命与可靠性：高频通断的寿命预算

继电器是有机械寿命的。GSCW1M2P 给出两个寿命指标，含义完全不同：

这两个数字差了两个数量级，正是新手最容易忽略的地方。机械寿命 500 万次听起来"这辈子用不完"，但真正消耗寿命的是"带电通断"，也就是电气寿命——只有 5 万次。

举个"寿命预算"的例子（示例测算）：假设你在做一个"每小时开关一次的冷库补光"项目，一天 24 次，一年约 8760 次。若按电气寿命 5 万次估算，大约 5.7 年就会接近设计寿命；如果做到"每 5 分钟开关一次"，一天 288 次，不到半年就把电气寿命耗掉大半。这不是危言耸听，而是提醒你：凡是高频通断场景，一定要先算寿命账。

工程结论：

2.3 能力边界：单路、接线式、不防水

规格表之外，还有三条必须刻在脑子里的边界，它们决定了"能用"和"不能用"。

边界一：单路。
它只有一路输出。一个通断器 = 一个回路。三台设备要独立控制，就是三台通断器、三条回路。别指望它像"三路开关面板"一样一拖三。

边界二：接线式，非插头。
GSCW1M2P 是接线式安装：需要**进线（来自空开/上级回路）和出线（去往负载）**两端接线，串进回路里。这意味着：

边界三：不防水。
本产品不防水，只能安装在干燥、无凝露、无直接水淋的室内环境（配电箱、室内底盒）。严禁装在水池边、室外露天、浴室蒸汽区等潮湿场所。若现场潮湿，必须另加防护箱体并做好密封。

边界四（最容易被忽视）：感性负载必须降额。
"MAX 6000W"针对的是阻性负载——电热丝、白炽灯、电阻炉这类，电流与电压同相、启动冲击小。而电机、压缩机、水泵属于感性负载，启动瞬间电流可达额定值的数倍（常见的 3~7 倍）。一台额定 2kW 的电机，启动峰值可能冲到 6~14kW，远超通断器的承受能力。

因此，感性负载场景必须：

• 降额使用：按额定电流的 1/2 甚至更低去配（例如 25A 通断器去带额定 10A 以内的感性负载），留足余量。
• 加接触器 / 软启动器：让通断器只负责"发号施令"，真正切断大电流的任务交给接触器，用软启动抑制启动冲击。
• 单独评估：压缩机类（空调、冰柜）启动最"凶"，务必单独测算启动电流。

一句话：6000W 是给阻性负载的；感性负载请降额 + 加中间器件，别硬接。

2.4 视在功率：插座 / 通断器上报的是视在功率

这是全文最"烧脑"、也最影响你验收的一个概念，一定要讲清楚。

电学里有三种功率：

• 有功功率 P（单位 W）：真正做功、真正计费的那部分。
• 无功功率 Q（单位 var）：在电感和电容之间来回串门、不做功的那部分。
• 视在功率 S（单位 VA）：电压有效值 × 电流有效值的乘积，是"看着有多大"，S² = P² + Q²。

GSCW1M2P 上报的 power 字段是视在功率（VA/W 口径下的电压电流乘积）。 它直接把 voltage × current 算出来，不区分有功无功。这对纯阻性负载（电热水器、白炽灯）几乎等于有功功率，误差很小；但对感性负载（电机、带电源适配器的设备、变频空调），视在功率会明显大于有功功率。

这对你意味着什么？

用表格帮你记：

工程提醒：做"电费审计"类功能时，凡遇到电机、变频器、开关电源类负载，都要在文档或界面上注明"此为视在功率口径，如需计费请按功率因数折算"，避免用户拿了数就当成电费。

本章要点

落地清单

• 确认负载类型：阻性还是感性？额定功率 / 电流多少？
• 若是感性负载，测算启动电流，确定降额比例或加装接触器。
• 核对线径是否 ≥4mm²（或符合当地规范），配好空开 / 漏保。
• 确认安装环境干燥、无凝露、不涉水。
• 评估通断频率，对照电气寿命 5 万次做寿命预算。

第 3 章 协议与指令全景

一句话点题：GSCW1M2P 提供给开发者的"接口"就是三种协议加一套指令表，看懂"谁发布、谁订阅"和"请求—响应"模型，你就掌握了控制它的全部钥匙。

3.1 MQTT / TCP / HTTP 三种方式怎么选

设备支持三种控制协议，各有适用场景：

选型口诀（示例建议）：

值得一提的是，GSCW1M2P 的一大卖点是可接入自建服务器，与厂商云解耦、无捆绑、无隐性成本。你完全可以把设备指向自己的 MQTT Broker（通过 setting-mqtt）或自己的 TCP 服务（通过 setting-tcp），数据和控制权都在你自己手里。修改服务器配置后需要断电重启，或通过 controller-restart 重启设备才能生效——这一点务必写进你的部署 SOP。

3.2 主题语义的反直觉

这是新手最容易翻车的地方，请逐字读三遍。

设备通过 info-protocol 指令返回当前通信协议配置，字段包括 server、port、publish、subcribe、clientId、username、protocol。其中两个主题字段的语义，取的是"设备视角"，而不是"平台视角"：

• publish：设备发布数据的主题 —— 所以平台要订阅它，才能收到设备上报的用电数据和响应。
• subcribe：设备订阅的主题 —— 所以平台要往这里发布（下指令）。

反直觉点一：字段名是设备视角。看到 publish 就想"我要发布？"——错，是设备发布、你来订阅。

反直觉点二：subcribe 是固件里固定的拼写（少了 c，正确英文是 subscribe）。不要"好心"把它改成 subscribe，改了就跟固件的主题对不上，指令发不出去。这是固件既定的字符串，照用即可。

记忆口诀：

publish 是"设备说给我听"，我订阅；subcribe 是"设备听我说"，我发布。

3.3 指令全表速览与「请求—响应」模型

设备以"下行为主"（平台下发、设备响应），每条请求带一个 messageId 业务流水号，设备会原样回显，方便你把响应和请求对上号。

「请求—响应」模型可以概括为：

其中 type 字段有三类语义："event"（事件类，如通断电）、"setting"（设置类，如改配置）、"info" / "statistic"（查询类，如读信息、读用电）。理解这三个 type，就能一眼看出这条指令"是干什么的"。

3.4 用电数据结构

用电相关数据在两个地方出现，字段一致（voltage、current、power、energy），来源不同：

• 设备主动上报：device-timer-task，source 为 "auto"，按你设置的频率定时推来。字段：commandName:"device-timer-task"、voltage、current、power、energy、key、mac、source:"auto"。
• 平台主动查询：info-statistic，你发 type:"statistic" 去问，设备回。字段：commandName:"info-statistic"、voltage、current、power、energy、key、mac、messageId、source。

四个核心字段的含义：

key 字段反映当前继电器状态（0 断电 / 1 通电），mac 是设备标识，方便一平台多设备时区分来源。

本章要点

落地清单

• 用 info-protocol 读回 publish / subcribe / server / port，确认主题与服务器。
• 平台端订阅 publish 主题、向 subcribe 主题发布，切勿写反。
• 所有下行指令带上 messageId，并实现"按 messageId 匹配响应"的回调。
• 用 setting-mqtt / setting-tcp 指向自建服务器后，记得断电重启或 controller-restart。
• 设计用电数据解析：voltage / current / power / energy 分别落库。

第 4 章 快速上手：15 分钟控制一台大功率设备（三语言）

一句话点题：下面这套流程，从断电接线到代码跑通、拿到用电数据，最快 15 分钟就能完成——前提是接线由专业人员、并严格遵守强电安全规范。

4.1 准备：断电接线、上电、配网、确认主题

第 0 步：断电。 切断上级空气开关，用验电笔 / 万用表确认线路无电。（若你没有电工资质，请把这一步交给专业人员。）

第 1 步：接线。 把上级回路的进线接入通断器输入端，出线接到负载（去往空调 / 热水器 / 电机回路）。确保线径匹配（参考 ≥4mm² 铜芯），空开 / 漏保容量足够，接线端子拧紧。

第 2 步：上电。 合上空气开关，观察设备指示灯是否正常。

第 3 步：配网。 按设备说明进入配网模式，用手机把设备接入 2.4GHz WiFi（注意：仅支持 2.4GHz，5GHz 连不上）。

第 4 步：确认主题。 让设备连上厂家默认 MQTT 测试服务器，或用 setting-mqtt 改到你的服务器。然后下发 info-protocol，记下返回的 publish（平台订阅）、subcribe（平台发布）、server、port。改过服务器配置的，务必断电重启或 controller-restart 让其生效。

完成后，你手里就有：一台在线设备 + 一组主题。接下来进入代码环节。

4.2 Python 最小示例（paho-mqtt）

下面的 Python 示例演示完整链路：连接 → 订阅 publish → 发 controller-event 通电 → 收到响应 → 查询用电。

import json, time
import paho.mqtt.client as mqtt

# 注意：以下主题为示意占位，实际请以 info-protocol 返回的 publish/subcribe 为准
BROKER = "mqtt.example.com"
PORT = 1883
CLIENT_ID = "gscw-demo-python"
CMD_TOPIC = "device/gscw1m2p/DEMO/subcribe" # 设备订阅 → 平台发布（下指令）
DATA_TOPIC = "device/gscw1m2p/DEMO/publish" # 设备发布 → 平台订阅（收数据）

def on_connect(client, userdata, flags, rc):
print("已连接 broker, rc =", rc)
client.subscribe(DATA_TOPIC) # 订阅设备上报的主题

def on_message(client, userdata, msg):
payload = json.loads(msg.payload.decode())
name = payload.get("commandName")
if name == "controller-event":
print("通断电响应: key=%s onState=%s" % (payload.get("key"), payload.get("onState")))
elif name == "info-statistic":
print("用电: V=%s A=%s W=%s kWh=%s" % (
payload.get("voltage"), payload.get("current"),
payload.get("power"), payload.get("energy")))

client = mqtt.Client(client_id=CLIENT_ID)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, 60)
client.loop_start()

# 1) 通电（key=1 通电 / key=0 断电），带 messageId 便于匹配响应
client.publish(CMD_TOPIC, json.dumps({
"commandName": "controller-event", "key": 1, "type": "event", "messageId": "1001"}))
time.sleep(1)

# 2) 查询实时用电
client.publish(CMD_TOPIC, json.dumps({
"commandName": "info-statistic", "type": "statistic", "messageId": "1002"}))
time.sleep(3)

client.loop_stop()

运行后，你应当先在控制台看到"通断电响应"，再看到一行用电数据。

4.3 Node.js 与 Java 最小示例

Node.js（约 20 行）：

const mqtt = require('mqtt');
const CMD = 'device/gscw1m2p/DEMO/subcribe'; // 平台发布：下指令
const DATA = 'device/gscw1m2p/DEMO/publish'; // 平台订阅：收数据

const c = mqtt.connect('mqtt://mqtt.example.com:1883', { clientId: 'gscw-demo-node' });

c.on('connect', () => {
c.subscribe(DATA);
c.publish(CMD, JSON.stringify({ commandName: 'controller-event', key: 1, type: 'event', messageId: '2001' }));
});

c.on('message', (topic, buf) => {
const msg = JSON.parse(buf.toString());
if (msg.commandName === 'controller-event') console.log('响应: onState=', msg.onState);
if (msg.commandName === 'info-statistic') console.log('用电: W=', msg.power, 'kWh=', msg.energy);
});

Java（Eclipse Paho，约 25 行）：

import org.eclipse.paho.client.mqttv3.*;
import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;

public class GscwDemo {
public static void main(String[] args) throws Exception {
String CMD = "device/gscw1m2p/DEMO/subcribe"; // 平台发布
String DATA = "device/gscw1m2p/DEMO/publish"; // 平台订阅

MqttClient client = new MqttClient("tcp://mqtt.example.com:1883", "gscw-demo-java", new MemoryPersistence());
client.connect();

client.subscribe(DATA, (topic, msg) ->
System.out.println("收到: " + new String(msg.getPayload())));

String body = "{\\"commandName\\":\\"controller-event\\",\\"key\\":1,\\"type\\":\\"event\\",\\"messageId\\":\\"3001\\"}";
client.publish(CMD, new MqttMessage(body.getBytes()));
Thread.sleep(3000);
client.disconnect();
}
}

三个示例的结构完全一致：订阅 publish、向 subcribe 发布、按 commandName 分发消息。语言只是外壳，模型是同一个。

4.4 完整脚本：开关 + 用电数据采集 + 上报频率设置

下面把"通断电控制"“查询用电”"设置定时上报频率"三件事合成一个可用的 Python 脚本。它先设置设备每 30 秒自动上报一次用电，再通电，然后持续接收数据。

import json, time
import paho.mqtt.client as mqtt

BROKER, PORT = "mqtt.example.com", 1883
CMD_TOPIC = "device/gscw1m2p/DEMO/subcribe" # 平台发布
DATA_TOPIC = "device/gscw1m2p/DEMO/publish" # 平台订阅

def on_connect(client, userdata, flags, rc):
client.subscribe(DATA_TOPIC)

def on_message(client, userdata, msg):
d = json.loads(msg.payload.decode())
n = d.get("commandName")
if n == "device-timer-task": # 设备按频率主动上报
print("[自动上报 source=%s] V=%s A=%s W=%s kWh=%s" % (
d.get("source"), d.get("voltage"), d.get("current"),
d.get("power"), d.get("energy")))
elif n == "info-statistic": # 平台查询的实时数据
print("[实时查询] W=%s kWh=%s" % (d.get("power"), d.get("energy")))
elif n == "device-timer-interval": # 设置频率的响应
print("[频率设置] enable=%s interval=%s success=%s" % (
d.get("timerEnable"), d.get("timerInterval"), d.get("success")))

client = mqtt.Client(client_id="gscw-demo-full")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, 60)
client.loop_start()

# 1) 设置定时上报：启用(timerEnable=1)，每 30 秒一次（timerInterval 范围 5~86400 秒）
client.publish(CMD_TOPIC, json.dumps({
"commandName": "device-timer-interval",
"timerEnable": 1, "timerInterval": 30,
"type": "setting", "messageId": "4001"}))
time.sleep(1)

# 2) 通电
client.publish(CMD_TOPIC, json.dumps({
"commandName": "controller-event", "key": 1, "type": "event", "messageId": "4002"}))
time.sleep(1)

# 3) 主动查询一次实时用电
client.publish(CMD_TOPIC, json.dumps({
"commandName": "info-statistic", "type": "statistic", "messageId": "4003"}))
time.sleep(2)

# 4) 保持连接，接收自动上报（示例持续 60 秒）
time.sleep(60)

# 5) 收尾断电（按需）
client.publish(CMD_TOPIC, json.dumps({
"commandName": "controller-event", "key": 0, "type": "event", "messageId": "4004"}))
time.sleep(2)

client.loop_stop()

运行过程中你会同时看到三类输出：device-timer-task（自动上报）、info-statistic（查询返回）、device-timer-interval（频率设置确认）。至此，你已经掌握了"控电 + 计量 + 频率调节"三位一体的最小闭环。

4.5 本章落地清单

• 接线前断电、验电；接线由专业电工完成，线径与空开/漏保按规范配置。
• 设备接入 2.4GHz WiFi，用 info-protocol 确认 publish / subcribe 及服务器信息。
• 平台正确订阅 publish、向 subcribe 发布，主题切勿写反。
• 用 controller-event（key=1 通电 / 0 断电）完成一次远程通断电验证。
• 用 info-statistic 查询一次实时用电，确认 voltage / current / power / energy 正常返回。
• 用 device-timer-interval（timerEnable=1，timerInterval=5~86400 秒）设置自动上报频率。
• 所有下行指令携带 messageId，并在代码中按 messageId 匹配响应。
• 若改过服务器配置，执行断电重启或 controller-restart 使其生效。
• 感性负载已做降额 / 加装接触器；高频通断场景已核算电气寿命（5 万次）。

本章要点

本部分结束。 第 1 部分带你建立了对 GSCW1M2P 的整体认知、看懂了协议与指令全景，并跑通了第一个可用脚本。后续部分将深入指令细节、异常处理、批量管理与工程部署。请务必牢记：这是强电设备，任何接线与改造都必须断电并由专业人员操作。

第 5 章 大功率用电采集与计量

一句话点题：GSCW1M2P 不只是一个"能通断电的开关"，它还是一个装在配电箱里、可以远程读数的单相电能计量点——本章把这些数字从哪来、准不准、怎么算成电费、怎么存下来，一次讲清。

GSCW1M2P 是单路通断器（不是三路开关），输入 110~260Vac、工作电流 25A、最大 6000W（阻性），自带用电采集：电压(V)、电流(A)、视在功率(W)、累计用电量(kWh)。这些数据通过 MQTT/TCP/HTTP 上报，是你做能耗分析、电费统计、异常告警的原料。

5.1 采集原理与精度影响因素

5.1.1 它是怎么"看"到电的

设备内部有三段采样链路，可以类比成体检：

主控是乐鑫 ESP8266，它负责把采样结果换算成字段，并按周期通过 MQTT 发出去。

5.1.2 上报字段（来自真实契约）

无论是设备主动上报还是平台查询，用电数据的字段名是固定的：

⚠️ 划重点：power 报的是视在功率（VA 口径），不是有功功率。5.2 节专门讲这个坑。

5.1.3 一条真实上报长什么样

import json

def on_message(client, userdata, msg):
payload = json.loads(msg.payload.decode("utf-8"))
cmd = payload.get("commandName")
# 两种上行都带用电字段：定时上报 & 主动查询响应
if cmd in ("device-timer-task", "info-statistic"):
print(
f"[{payload.get('mac')}] "
f"V={payload.get('voltage')} "
f"I={payload.get('current')} "
f"P={payload.get('power')}W "
f"E={payload.get('energy')}kWh "
f"key={payload.get('key')} "
f"source={payload.get('source')}"
)

5.1.4 精度影响因素（决定"准不准"）

结论：energy 是设备端累计量，比较可靠；power 是瞬时视在功率，适合做趋势/告警，不适合拿去精确计费。需要法定计量级精度，应另配专业电能表。

5.2 视在功率 vs 有功功率 vs 电费

5.2.1 一个"啤酒杯"类比

把电想成一杯啤酒：

• 泡沫 + 酒 = 视在功率 S（VA） → 也就是设备上报的 power
• 真正喝下去的酒 = 有功功率 P（W） → 真正做功、真正电表计价的部分
• 泡沫 = 无功功率 Q（var） → 电感/电容来回"打气"，不干活但也占用容量

关系：S = U × I，P = S × cosφ = S × PF，其中 PF（功率因数）在 0~1 之间。

5.2.2 电费到底按哪个算

• 居民/普通商业电表计费的是有功电量 kWh；
• 设备上报的 energy 是设备的"口径"，对纯阻性负载几乎等于有功电量，对感性负载会有偏差；
• 工业大用户还有"力率调整电费"（功率因数低会被罚款），这时 PF 就非常关键。

5.2.3 换算示例测算

（上表为示例测算，实际 PF 以铭牌为准。）

换算代码：

def active_power(power_va: float, pf: float = 0.85) –> float:
"""把设备上报的视在功率换算成有功功率（无 PF 数据时用经验值）。"""
return round(power_va * pf, 1)

# 示例：设备报 2000W，按 0.85 估
print(active_power(2000, 0.85)) # 1700.0 W

5.2.4 工程建议清单

5.3 定时上报 vs 主动查询，怎么选

设备给了两条取数路径，各有适用场景。

5.3.1 定时上报：先"打开开关"

出厂后设备可能默认不主动上报，必须先用 device-timer-interval 打开并设置周期：

def new_message_id() –> str:
import time
return time.strftime("%Y%m%d%H%M%S") + "000"

# 开启定时上报，周期 60 秒（示例）
cmd = {
"messageId": new_message_id(),
"timerEnable": 1,
"timerInterval": 60, # 单位秒，允许 5~86400
"type": "setting",
}
client.publish(command_topic, json.dumps(cmd)) # command_topic = info-protocol 的 subcribe

设备会回一条 device-timer-interval 响应，含 timerEnable、timerInterval、success。

5.3.2 主动查询：拿来即用的即时值

# 主动查询一次实时用电（用于用户点开面板刷新）
query = {"messageId": new_message_id(), "type": "statistic"}
client.publish(command_topic, json.dumps(query))
# 设备回 info-statistic：voltage / current / power / energy / key / mac / messageId / source

5.3.3 取舍建议（什么时候用哪个）

5.4 能耗分析方法

5.4.1 负载画像：先看清"谁在用电"

把一天的 power 按小时画出来，就能看出设备作息：

from collections import defaultdict

def load_profile(samples):
"""samples: [(ts_epoch, power_w), …] -> {hour: 平均功率}"""
buckets = defaultdict(list)
import time
for ts, p in samples:
hour = time.localtime(ts).tm_hour
buckets[hour].append(p)
return {h: round(sum(v) / len(v), 1) for h, v in sorted(buckets.items())}

5.4.2 待机功耗：看不见的"电费小偷"

• 设备自身待机功率 <4W；
• 负载本身的待机（如机顶盒、充电器、饮水机保温）才是大头。

判定与测算：

STANDBY_THRESHOLD_W = 10 # 低于此功率且通电中，判为待机（示例阈值）

def standby_energy_kwh(power_w, hours=24 * 365):
return round(power_w * hours / 1000, 2)

# 示例测算：负载待机 3W
print(standby_energy_kwh(3)) # 26.28 kWh/年

示例测算：一台待机 3W 的设备，一年空耗约 26.28 kWh；按 0.6 元/度估算约 15.8 元。几十台叠加就很可观，"夜间自动断待机"往往是最快的节能动作。

5.4.3 异常用电：用"基线对比"抓问题

5.4.4 峰谷用电：配合分时电价

按电网分时电价（峰/平/谷）对 energy 做区间差分，得出各时段电量：

def delta_energy_kwh(prev_kwh, now_kwh):
d = now_kwh – prev_kwh
# energy 被 energy-clear 清零或设备重启时可能跳变，做保护
return d if d >= 0 else 0.0

# 示例测算：谷段 0.3 元/度、峰段 1.0 元/度
def cost(delta_kwh, price):
return round(delta_kwh * price, 2)
print(cost(10, 1.0)) # 峰段 10 度 -> 10.0 元
print(cost(10, 0.3)) # 谷段 10 度 -> 3.0 元

策略：把大功率设备（热水器、充电、水泵）尽量挪到谷段运行，可通过平台自动化定时触发 controller-event 实现。

5.5 数据落库与可视化

5.5.1 时序库选型

5.5.2 存储量估算

单条记录字段约：ts, mac, voltage, current, power, energy（约 60~80 字节）。

（上表为示例测算，按每条约 80 字节计；100 台 60s 上报约 4.2 GB/年。）

5.5.3 落库示例（SQLite）

import sqlite3, time

conn = sqlite3.connect("energy.db")
conn.execute("""
CREATE TABLE IF NOT EXISTS samples (
ts INTEGER NOT NULL, — epoch 秒
mac TEXT NOT NULL,
voltage REAL, — V
current REAL, — A
power REAL, — W (视在功率)
energy REAL — kWh 累计
);
""")
conn.execute("CREATE INDEX IF NOT EXISTS idx_mac_ts ON samples(mac, ts);")

def save(mac, payload):
conn.execute(
"INSERT INTO samples(ts, mac, voltage, current, power, energy)"
" VALUES (?,?,?,?,?,?)",
(int(time.time()), mac,
payload.get("voltage"), payload.get("current"),
payload.get("power"), payload.get("energy")),
)
conn.commit()

5.5.4 降采样与保留策略

• 冷热分层：原始数据留 30 天，分钟级留 1 年，小时级长期保存；
• 降采样：用后台任务把原始点聚合成 5 分钟/1 小时均值，减小体积；
• 可视：Home Assistant 能源面板、Grafana、或自研前端（参考本项目 frontend/ 的实时曲线组件）。

本章要点 / 落地清单

• 认清字段：voltage/current/power/energy，其中 power 是视在功率。
• 电费用有功电量：阻性直接算，感性乘 PF（默认 0.8 估）。
• 常态用 device-timer-interval 定时上报（30~60s 起步），交互用 info-statistic。
• 用 energy 差分算区间电量，用 power 做趋势与异常告警。
• 按上报间隔估存储量，做好降采样与保留策略。

第 6 章 调试手册：从"没反应"到"一眼定位"

一句话点题：绝大多数"设备没反应"的问题，都能用一条数据流链路（设备 → Broker → 订阅方）和两条抓包命令在 5 分钟内定位——本章给你一套可复制的排查 SOP。

6.1 三层排查法（Broker → 主题 → 设备）

把数据流画成一条线，任何故障必然卡在某一段：

[GSCW1M2P 设备] –(1)网络/连接–> [MQTT Broker] –(2)主题匹配–> [订阅方: 平台/HA/脚本]
▲ ▲ ▲
第 3 层 第 1 层 第 1 层
(设备侧) (Broker侧) (应用侧)

排查顺序：自下而上、从中间捅——先确认 Broker 活着，再看主题通不通，最后落到设备。

一个快速判定矩阵：

6.2 mosquitto_sub / mosquitto_pub 抓包定位

6.2.1 先确认 Broker 凭据与主题

设备当前的连接信息来自 info-protocol：server、port、publish、subcribe、clientId、username。

⚠️ 最容易搞反的一点：

• publish = 设备发布数据的主题 → 你要订阅它（收数据）；
• subcribe = 设备订阅的主题（固件原文拼写，别"改对"）→ 你要发布到它（下指令）。

6.2.2 两条保命命令

# ① 看"设备是否在发数据"——订阅设备上报主题（= info-protocol 的 publish）
mosquitto_sub -h 192.168.1.10 -p 1883 -u device -P device-pass \\
-t 'gemeopen/gscw1m2p/+/report' -v

# ② 看"是否有人给设备发指令"——订阅设备指令主题（= info-protocol 的 subcribe）
mosquitto_sub -h 192.168.1.10 -p 1883 -u device -P device-pass \\
-t 'gemeopen/gscw1m2p/+/command' -v

用 + 通配符可同时观察多台设备。若 ① 有 JSON 持续滚出 → 设备侧 OK，问题在应用；若 ① 一片安静 → 往设备侧查。

6.2.3 手动下发一条指令（验证"平台→设备"）

# 手动开一次定时上报（周期 60s）
mosquitto_pub -h 192.168.1.10 -p 1883 -u device -P device-pass \\
-t 'gemeopen/gscw1m2p/28372fcbbbb8/command' \\
-m '{"messageId":"1","timerEnable":1,"timerInterval":60,"type":"setting"}'

# 手动通电（key=1）
mosquitto_pub -h 192.168.1.10 -p 1883 -u device -P device-pass \\
-t 'gemeopen/gscw1m2p/28372fcbbbb8/command' \\
-m '{"messageId":"2","key":1,"type":"event"}'

发完立刻在命令 ① 里看是否回显 commandName、success 或带 key 的上行——有回显说明"下行通路"打通。

6.2.4 主题命名约定（本项目建议）

出厂默认连 GemeOpen 厂家 MQTT 测试服务器；用 setting-mqtt/setting-tcp 改到自建服务器，改后需断电重启或 controller-restart 生效。修改前请先记录 info-protocol 里的原始主题。

6.3 常见故障速查表

A. 连接类

B. 上报类

C. 控制类

D. 电量/计量类

E. 平台/应用类

（共 27 条，覆盖连接/上报/控制/计量/平台五类。）

6.4 强电侧与弱电侧联合排查

GSCW1M2P 是接线式安装：进线/出线要接，一边是 220V 强电，一边是 WiFi/MQTT 弱电通信。故障可能来自任一侧，必须分开验。

四步法定位：

⚠️ 安全红线：任何接线、拆线、换空开，必须断电作业、由专业电工操作。别带电摸端子。

本章要点 / 落地清单

• 记住数据流：设备 → Broker → 订阅方，按"Broker→主题→设备"三层排查。
• 常备两条命令：mosquitto_sub 看上报、mosquitto_pub 验下行。
• 牢记 publish（你要订阅）/subcribe（你要发布）别搞反。
• 强电、弱电分开验，先断电再动线。
• 把 6.3 速查表存到运维文档，故障时按症状直查。

第 7 章 二次开发进阶：把它变成你的产品

一句话点题：从"能用"到"好用"的差距，全在封装、命名、批量配置和可靠性这四件事上——本章把它们做成可复用的工程套路。

7.1 SDK 封装：连接 / 重连 / 请求-响应 / 设备影子

一个合格的 SDK 要解决四件事：稳连、自动重连、请求-响应配对、状态影子。

7.1.1 稳连与自动重连

import json, threading, time
from itertools import count
import paho.mqtt.client as mqtt
from paho.mqtt.enums import CallbackAPIVersion

class GscwClient:
def __init__(self, host, port, username=None, password=None,
client_id="gscw-sdk", report_topic=None, command_topic=None):
self.report_topic = report_topic # 设备 publish，你订阅
self.command_topic = command_topic # 设备 subcribe，你发布
self._ids = count(1)
self._pending = {} # messageId -> 响应
self._lock = threading.Lock()

self.client = mqtt.Client(CallbackAPIVersion.VERSION2, client_id=client_id)
if username:
self.client.username_pw_set(username, password or "")
# 断线自动重连：1s 起，指数退避到 30s
self.client.reconnect_delay_set(min_delay=1, max_delay=30)
self.client.on_connect = self._on_connect
self.client.on_message = self._on_message
self.host, self.port = host, port

def connect(self):
self.client.connect_async(self.host, self.port, keepalive=60)
self.client.loop_start()

def _on_connect(self, client, userdata, flags, reason_code, properties=None):
# 关键：重连后必须重新订阅，否则收不到上报
client.subscribe(self.report_topic, qos=0)

def _on_message(self, client, userdata, msg):
try:
data = json.loads(msg.payload.decode("utf-8"))
except Exception:
return
mid = data.get("messageId")
with self._lock:
if mid in self._pending:
self._pending[mid].update(data)

7.1.2 请求-响应配对

def _next_id(self):
return time.strftime("%Y%m%d%H%M%S") + f"{next(self._ids):03d}"

def request(self, cmd: dict, timeout=5.0):
"""下发指令并等待含相同 messageId 的响应。"""
mid = self._next_id()
cmd = {**cmd, "messageId": mid}
slot = {}
with self._lock:
self._pending[mid] = slot
self.client.publish(self.command_topic, json.dumps(cmd), qos=0)
deadline = time.time() + timeout
while time.time() < deadline:
if slot:
break
time.sleep(0.1)
with self._lock:
self._pending.pop(mid, None)
return slot or None

def switch(self, key: int):
# key: 0=断电, 1=通电
return self.request({"key": key, "type": "event"})

def query_statistic(self):
return self.request({"type": "statistic"})

7.1.3 设备影子（本地状态缓存）

设备可能离线、上报可能丢帧，所以维护一份"最后已知状态"：

def _on_message(self, client, userdata, msg):
try:
data = json.loads(msg.payload.decode("utf-8"))
except Exception:
return
# 更新影子：只覆盖本次出现的字段
for k in ("voltage", "current", "power", "energy", "key", "signal", "onState"):
if k in data:
self.shadow[k] = data[k]
self.shadow["last_seen"] = time.time()
# 请求-响应配对
mid = data.get("messageId")
with self._lock:
if mid in self._pending:
self._pending[mid].update(data)

shadow 里保留 key（继电器状态）、energy（累计电量）、last_seen（心跳时间），前端就能离线展示"最后状态"。

7.2 多设备与多回路管理

GSCW1M2P 是单路设备，一路一个回路。多设备管理的关键是命名规范 + 主题规划。

7.2.1 命名规范（示例）

gemeopen/gscw1m2p/<mac>/report # 设备上报（你订阅）
gemeopen/gscw1m2p/<mac>/command # 设备指令（你发布）
<mac> = 小写十六进制，如 28372fcbbbb8

7.2.2 业务别名映射（推荐维护一张表）

代码里用"别名 → mac → 主题"三级映射，前端就不必关心 MAC。

TOPIC = "gemeopen/gscw1m2p/{mac}/{kind}"
def topics_for(mac):
return {
"report": TOPIC.format(mac=mac, kind="report"),
"command": TOPIC.format(mac=mac, kind="command"),
}

7.2.3 多回路注意

• 每台设备独立回路、独立空开，不要多台共用一台空开；
• 每条上行都要看 mac，防止主题用通配符后张冠李戴；
• 后端订阅用 gemeopen/gscw1m2p/+/report 一次接管全部设备。

7.3 批量配置

部署多台时，几条"setting-*"指令可显著降低现场工作量。

7.3.1 批量脚本骨架

CONFIGS = [
{"messageId": "1", "onState": 1, "type": "setting"}, # 上电默认关闭
{"messageId": "2", "keyLock": 1, "type": "setting"}, # 打开按键锁
{"messageId": "3", "wifiLock": 1, "type": "setting"}, # 打开配网锁
{"messageId": "4", "timerEnable": 1, "timerInterval": 60, "type": "setting"},
]

def provision(cli: GscwClient):
for cmd in CONFIGS:
resp = cli.request(cmd)
print(cmd["type"], "->", "OK" if resp and resp.get("success") else resp)

注意：onState 取值 0/1/2 与 keyLock/wifiLock 的 0/1 含义不同，别混用。设备回 success 字段表示是否生效。

7.3.2 现场建议

7.4 可靠性：断网缓存、重试、幂等、电量清零

7.4.1 断网与重连

• 设备侧断网后不补报历史数据，所以平台应把"最新一次 energy"当作权威累计值；
• 应用侧用 reconnect_delay_set + on_connect 重新订阅（见 7.1）。

7.4.2 重试与超时

def request_with_retry(cli, cmd, retries=3, timeout=5.0):
for i in range(retries):
resp = cli.request(cmd, timeout=timeout)
if resp:
return resp
time.sleep(1.0 * (i + 1)) # 退避
return None

7.4.3 幂等：同一件事做多次不出错

• 控制指令天然幂等：key=1 连发多次仍是"通电"；
• 配置指令也幂等：重复设 timerInterval=60 结果一致；
• 累计电量不是幂等量：不要"累加"上报值，而要取最新值。

7.4.4 energy-clear 的正确使用

energy-clear 会把累计电量清零，返回 success。它只适用于"换新周期/换用户/计费结算"这类场景，用错会导致报表跳变。

正确用法：

class EnergyLedger:
"""维护"历史累计 + 当前设备值"的账本，容忍 energy-clear。"""
def __init__(self):
self.offset = 0.0 # 历史清零前的累计
self.last_dev = 0.0 # 上一次设备读数

def on_sample(self, dev_energy: float):
if dev_energy < self.last_dev: # 检测到清零
self.offset += self.last_dev
self.last_dev = dev_energy
return round(self.offset + dev_energy, 3) # 真实累计

本章要点 / 落地清单

• 封装 SDK：稳连 + 自动重连（on_connect 重订阅）+ 请求-响应配对 + 影子缓存。
• 主题按 <mac> 规划，维护"别名↔mac"映射表。
• 用 setting-on-state/setting-key-lock/setting-wifi-lock 做批量配置与现场加固。
• 控制/配置靠幂等设计，电量靠"账本偏移"容忍 energy-clear。
• 记住设备寿命：机械 500 万次、电气 5 万次，高频通断要算寿命预算。

第 8 章 云平台对接与系统集成

一句话点题：GSCW1M2P 与厂商云解耦、无捆绑、无隐性成本，你可以把它接进私有 Broker、Home Assistant，或企业级 EMS/SCADA——本章给出可直接抄的配置。

8.1 私有化部署（自建 Mosquitto / EMQX + 服务）

8.1.1 为什么自建

• 数据留在自己手里，合规可控；
• 无厂商云依赖、无月费/隐性成本；
• 可与内网系统（EMS、工单）直连。

8.1.2 最小部署（Docker Compose）

services:
mosquitto:
image: eclipse–mosquitto:2
ports:
– "1883:1883"
– "9001:9001" # WebSocket（浏览器直连）
volumes:
– ./mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf
– ./mosquitto/data:/mosquitto/data
restart: unless–stopped

mosquitto.conf 关键项：

listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout

生成账号：

docker compose exec mosquitto mosquitto_passwd -c -b /mosquitto/config/passwd device device-pass
docker compose exec mosquitto mosquitto_passwd -b /mosquitto/config/passwd backend backend-pass

规模化可选 EMQX（集群、共享订阅、规则引擎）。设备侧用 setting-mqtt 指向它，再断电重启生效。

8.2 接入 Home Assistant（可直接用的 YAML）

前提：HA 已通过 UI 添加 MQTT 集成并连上你的 Mosquitto；设备已按 8.1 切到该 Broker；把所有 <MAC> 换成你的设备 MAC（小写）。把下面内容存为 mqtt-gscw1m2p.yaml，在 configuration.yaml 里加一行：mqtt: !include mqtt-gscw1m2p.yaml。

# ============================================================
# GemeOpen GSCW1M2P 智能通断器 25A —— Home Assistant 实体定义
# 前提：HA 已连接 Mosquitto；设备主题已指向自建 Broker
# 替换：所有 <MAC> -> 你的设备 MAC（小写，如 28372fcbbbb8）
# ============================================================

switch:
– name: "通断器 25A"
object_id: gscw1m2p_switch
unique_id: gscw1m2p_<MAC>_switch
icon: mdi:power
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
command_topic: "gemeopen/gscw1m2p/<MAC>/command"
# 上报 JSON 中：key=1 通电，key=0 断电
value_template: "{{ value_json.key }}"
payload_on: '{"key":1,"type":"event"}'
payload_off: '{"key":0,"type":"event"}'
state_on: 1
state_off: 0
optimistic: false
retain: false
qos: 0
device:
identifiers: ["gscw1m2p_<MAC>"]
name: "智能通断器 25A-S2 Plus"
manufacturer: "GemeOpen"
model: "GSCW1M2P (智能通断器 25A-S2 Plus-WiFi)"

sensor:
– name: "通断器 电压"
object_id: gscw1m2p_voltage
unique_id: gscw1m2p_<MAC>_voltage
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
value_template: "{{ value_json.voltage }}"
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
suggested_display_precision: 1
device:
identifiers: ["gscw1m2p_<MAC>"]

– name: "通断器 电流"
object_id: gscw1m2p_current
unique_id: gscw1m2p_<MAC>_current
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
value_template: "{{ value_json.current }}"
unit_of_measurement: "A"
device_class: current
state_class: measurement
suggested_display_precision: 3
device:
identifiers: ["gscw1m2p_<MAC>"]

# 注意：power 是“视在功率”（U×I），阻性负载下≈有功，感性负载会偏高
– name: "通断器 视在功率"
object_id: gscw1m2p_power
unique_id: gscw1m2p_<MAC>_power
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
value_template: "{{ value_json.power }}"
unit_of_measurement: "W"
device_class: power
state_class: measurement
suggested_display_precision: 1
device:
identifiers: ["gscw1m2p_<MAC>"]

– name: "通断器 累计用电量"
object_id: gscw1m2p_energy
unique_id: gscw1m2p_<MAC>_energy
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
value_template: "{{ value_json.energy }}"
unit_of_measurement: "kWh"
device_class: energy
state_class: total_increasing # 关键：能源面板靠它
suggested_display_precision: 3
device:
identifiers: ["gscw1m2p_<MAC>"]

– name: "通断器 信号强度"
object_id: gscw1m2p_signal
unique_id: gscw1m2p_<MAC>_signal
state_topic: "gemeopen/gscw1m2p/<MAC>/report"
value_template: "{{ value_json.signal if value_json.signal is defined else this.state }}"
unit_of_measurement: "dBm"
device_class: signal_strength
state_class: measurement
entity_category: diagnostic
device:
identifiers: ["gscw1m2p_<MAC>"]

启用后记得先开上报，否则传感器为"未知"：

mosquitto_pub -h 192.168.1.10 -p 1883 -u device -P device-pass \\
-t 'gemeopen/gscw1m2p/<MAC>/command' \\
-m '{"messageId":"1","timerEnable":1,"timerInterval":60,"type":"setting"}'

energy 设了 device_class: energy + state_class: total_increasing，会自动出现在 设置 → 仪表盘 → 能源。

8.3 与空调/热水器/水泵等大功率设备的联动

8.3.1 联动拓扑

[传感器/电价/时间] –> [自动化规则] –> [controller-event] –> [GSCW1M2P 继电器] –> [大功率负载]
(MQTT command 主题)

8.3.2 典型联动场景

HA 自动化示例（电价谷段开热水器）：

automation:
– alias: "谷段开热水器"
trigger:
– platform: time
at: "23:00:00"
action:
– service: switch.turn_on
target:
entity_id: switch.gscw1m2p_switch

– alias: "通断器过载保护"
trigger:
– platform: numeric_state
entity_id: sensor.gscw1m2p_power
above: 5500 # 示例阈值，留出 6000W 阻性上限余量
for: "00:00:30"
action:
– service: switch.turn_off
target:
entity_id: switch.gscw1m2p_switch
– service: persistent_notification.create
data:
title: "通断器过载"
message: "当前视在功率 {{ states('sensor.gscw1m2p_power') }} W，已断电保护"

8.3.3 大功率联动的三条铁律

8.4 对接 EMS / SCADA / 大屏 / 工单

对接要点：

本章要点 / 落地清单

• 自建 Mosquitto/EMQX，setting-mqtt 指向它并重启生效。
• HA 直接抄 8.2 YAML，替换 <MAC>，先开上报再验证实体。
• 联动优先"电价/时间/功率"三类触发，大功率走接触器。
• EMS/SCADA/大屏/工单按"统一模型 + 上行订阅 + 双向闭环"接入。

第 9 章 与传统电气设备对接

一句话点题：智能通断器再聪明，也要落到配电箱、导线、空开、漏保这些传统电气规则上——本章把"能装、能带、能扛"讲成一张施工清单。

⚠️ 总安全声明：本章所有接线、拆线、换件必须断电作业、由持证专业电工操作。产品MAX 6000W 是阻性负载上限，感性负载必须降额。

9.1 配电箱内的安装位置与回路规划

GSCW1M2P 尺寸 50mm × 110mm × 32mm，单路、接线式安装，一路一个回路。

9.1.1 安装位置建议

9.1.2 回路规划原则

9.2 大功率/多设备：用接触器扩功率（含接线示意）

继电器触点能力有限且电气寿命仅 5 万次。当负载接近或超过 25A/6000W，或负载是感性且启动电流大时，让通断器只驱动接触器线圈，由接触器主触点切负载。

9.2.1 为什么要"小控制、大执行"

• 通断器继电器：切小电流的接触器线圈（几十到几百 mA），寿命损耗小；
• 接触器主触点：接大负载，可承受几十安培、频繁动作；
• 类比：通断器是"指挥官"，接触器是"大力士"。

9.2.2 接线示意（文字版）

220V 相线 L ──┬───────────────[ 空开 ]───────────────┬── 接触器主触点 1(L1)
│ │
│ [ GSCW1M2P 进线 L ]──[ 出线 L(负载侧) ]──> 接触器线圈 A1
│
零线 N ─────┴───────────────────────────────────> 接触器线圈 A2

主电源 L ──[接触器主触点 2(T1)]──────────────────> 负载 火线
零线 N ────────────────────────────────────────> 负载 零线

要点：

示例测算：一台 3kW 阻性加热器，单靠通断器也能带（远低于 6000W）；但一台 5.5kW 三相/大功率水泵，启动电流可达额定 5~7 倍，必须用接触器 + 软启动，并选更大空开。

9.3 与空开、漏保、浪涌保护的配合

配合原则：

9.4 感性负载的启动电流与降额

9.4.1 为什么感性负载要特别小心

电机、压缩机、水泵、风机等感性负载启动瞬间电流可达额定的 5~8 倍，会产生：

• 触点电弧与粘连；
• 电流浪涌触发空开跳闸；
• 缩短继电器寿命（电气寿命 5 万次）。

9.4.2 典型启动倍数与降额建议

9.4.3 降额实操清单

示例测算：一台启动电流 5 倍、额定 4A 的水泵，启动瞬间约 20A，已接近 25A 上限；若用通断器直带，长期可靠性差，应改用接触器方案，通断器仅驱动线圈。

本章要点 / 落地清单

• 装在配电箱内、留散热、一回路一设备、强弱电分离。
• 大功率/感性负载用接触器扩功率，通断器只切线圈。
• 空开/漏保/SPD 分级配合，25A 回路配 ≥4mm² 铜芯线（以规范为准）。
• 感性负载必须降额、防启动浪涌、配热保护、避高频启停。
• 断电报操作、专业电工施工——这是所有电气工作的第一条。

本部分完 · 承接第 3~4 章（基础协议/指令），并为第 10 章起的应用案例与验收章节提供工程基础。所有金额与数值均为示例测算，实际以现场铭牌、电气规范与 GemeOpen 官方文档为准。

第三部分：自动化、安装施工、系统对接与场景实战

本篇承接前两部分的"协议与开发"，把 GSCW1M2P（智能通断器 25A-S2 Plus-WiFi）从"能联网的继电器"变成"能自动运行、能安全保护、能落地施工"的工程产品。第 10 章讲自动化与安全用电（全部基于平台侧逻辑 + 设备真实指令字段实现）；第 11 章讲"电工活"——接线、负载、保护、验收，这是 25A 大功率场景不可跨越的门槛；第 12 章讲与配电系统、工业设备的对接边界；第 13 章用 12 个真实场景把前面所有能力串起来。

安全总纲（全篇反复强调）：① 本设备是接线式安装，必须断电作业、由持证电工操作；② 25A、MAX 6000W 是"阻性负载"上限，感性负载（电机、压缩机、水泵）启动电流可达额定数倍，必须降额并加接触器/软启动；③ 导线线径须与 25A 匹配（参考 ≥4mm² 铜芯，具体以现场电气规范为准），并配容量足够的空开/漏保；④ 它是单路通断器，一路一个回路；⑤ 电气寿命仅 5 万次，高频通断要算寿命账。

第 10 章 自动化与安全用电：让大功率设备"听话且安全"

一句话点题：本章教你用设备真实指令 + 平台侧规则，把"远程按一下"升级为"到点自动开、越界自动断、死机自动重启、被传感器自动触发"。

10.1 定时通断（热水器定时加热、空调定时、水泵定时）

GSCW1M2P 自身提供的是数据定时上报能力，控制侧的"定时通断"有两种实现路径，二者可以叠加：

路径 A：平台侧定时（推荐，最灵活）。 平台用定时任务（cron / 调度器）在约定时刻下发 controller-event，让设备通断电。这种做法可跨天、跨节假日、可临时覆盖，适合"热水器每天 6:30 加热、空调 22:00 关机"这类业务。

路径 B：设备侧上报频率 + 平台联动。 通过 device-timer-interval 设置 timerEnable:"1"、timerInterval（秒，5~86400），让设备周期性上报 device-timer-task（含 voltage/current/power/energy），平台据此判断"是否已经加热到位"再决定切断，实现"保温到温即停"。

下指令的报文字段必须严格来自指令表。示例（Python / paho-mqtt，下同）：

import json, time
import paho.mqtt.client as mqtt

# 平台发出的 MQTT 主题 = 设备 info-protocol 返回的 "subcribe" 字段
# 平台订阅的主题 = 设备 info-protocol 返回的 "publish" 字段
CMD_TOPIC = "device/subcribe/topic" # 示例占位，实际以 info-protocol 返回为准
DATA_TOPIC = "device/publish/topic" # 示例占位，实际以 info-protocol 返回为准

def set_power(client, on: bool, seq: int):
"""下发通断电指令。key: 0=断电, 1=通电"""
payload = {
"commandName": "controller-event",
"type": "event",
"key": 1 if on else 0,
"messageId": seq, # 业务流水号，设备会原样回显
}
client.publish(CMD_TOPIC, json.dumps(payload), qos=1)

def set_report_interval(client, enable: bool, seconds: int):
"""设置用电数据定时上报。timerInterval 取值 5~86400 秒"""
payload = {
"commandName": "device-timer-interval",
"type": "setting",
"timerEnable": 1 if enable else 0,
"timerInterval": max(5, min(seconds, 86400)),
"messageId": int(time.time()),
}
client.publish(CMD_TOPIC, json.dumps(payload), qos=1)

典型配置清单（热水器定时加热）：① 平台在 6:20 下发 controller-event key=1；② 设置 device-timer-interval 每 60 秒上报一次；③ 平台收到 device-timer-task 后，若 power 连续两次低于待机阈值即判定"加热完成/设备已停"，记录能耗；④ 7:40 下发 key=0 兜底切断。整个过程用户不用管，“到点有热水、出门自动断”。

三个容易踩的坑：① 节假日/临时覆盖——把"每天定时"做成可覆盖的规则，用户临时在家时可手动 key=1 并自动顺延，不要写死；② 生效时机——setting-* 类配置（如自定义 MQTT）改后需断电重启或下发 controller-restart 才生效，定时策略改完记得验证；③ 断电后的状态——设备断电再来电时的默认动作由 setting-on-state 决定（0 记忆 / 1 关闭 / 2 开启），做定时场景一般选"记忆"最符合直觉。

10.2 安全策略：过载/异常用电的识别与自动断电（平台侧实现）

必须强调：GSCW1M2P 没有"过流阈值自动跳闸"这类原生阈值指令，设备只如实上报 voltage / current / power / energy（info-statistic 或定时上报的 device-timer-task）。因此所有"越界保护"都要在平台侧判断、再由平台下发 controller-event key=0 完成断电。这一点非常重要：如果平台失联，这层软件保护就失效，所以电气硬保护（空开/漏保/热继）永远是第一道防线（详见第 11 章保护配合）。

平台侧可实现的四类安全策略：

def on_message(client, userdata, msg):
data = json.loads(msg.payload.decode())
cmd = data.get("commandName")
# 定时上报或实时查询都会带回这几个关键字段
if cmd in ("device-timer-task", "info-statistic"):
cur = float(data.get("current", 0))
power = float(data.get("power", 0))
on_state = data.get("key") # 设备回显的当前通断状态

# 过载：电流越界持续告警
if cur > 22.0:
alert("过载告警：当前 %.1fA" % cur)
if cur > 24.0: # 逼近 25A 上限，立即断电
set_power(client, False, int(time.time()))
alert("已自动断电：电流 %.1fA 逼近 25A 上限" % cur)

# 异常用电：已断电却仍有电流 → 继电器粘连或线路异常
if on_state == 0 and cur > 0.5:
alert("严重：已断电但仍有电流 %.1fA，疑似继电器粘连，请人工断电检修" % cur)

# 过功率：MAX 6000W 为阻性上限，工程建议留余量
if power > 5000.0:
alert("功率偏高：%.0fW，接近 6000W 阻性上限，建议核查线径与空开" % power)

设计要点：阈值要留余量（不要把 25A 当常态），动作要有"持续 N 秒"去抖，避免电机启动瞬间的冲击电流误判；同时所有动作都要落库留痕，便于事后追责。建议把阈值做成分级：如 80% 提示、95% 告警、100% 断电，形成"预警—告警—切除"三级阶梯，既不误伤又守住底线。

10.3 无人值守与远程重启（现场设备死机远程断电重启）

很多现场设备（网关、路由器、水泵控制箱、广告机、充电桩主控）会"偶发死机"。传统做法是派人到现场拔插头。用 GSCW1M2P 把这类设备的供电进线串进去，就能实现"远程一键硬重启"：

• 对下游设备断电重启：下发 controller-event key=0，等待 10~30 秒，再下发 key=1，下游设备即完成一次冷启动。这是最常用的"无人值守重启"。
• 对通断器自身重启：下发 controller-restart（system:"restart"），让设备自己重启（不动继电器），适合设备网络假死时。
• 恢复出厂：controller-reset（system:"reset"）——慎用，会丢失配置。

def remote_reboot_downstream(client, off_seconds: int = 20):
seq = int(time.time())
set_power(client, False, seq) # 先断电
time.sleep(off_seconds) # 等电容放净、设备彻底停机
set_power(client, True, seq + 1) # 再上电，完成冷启动

def reboot_self(client):
"""重启通断器自身（不动作继电器）"""
client.publish(CMD_TOPIC, json.dumps({
"commandName": "controller-restart",
"type": "setting",
"system": "restart",
"messageId": int(time.time()),
}), qos=1)

注意点：① 断电重启前要确认下游设备允许意外断电（NAS、正在写盘的服务器不能硬切）；② 重启类操作要与 setting-on-state（上电默认状态）配合——设为 onState:0（记忆）可让意外断电后按原状态恢复，设为 onState:2（开启）可保证"来电即工作"；③ 建议加"重试上限"，避免无限重启放大故障。

10.4 与其他设备联动（温湿度/门磁/人体感应 → 控制大功率设备）

GSCW1M2P 本身不接传感器，但它是完美的执行末端：传感器数据进平台，平台做判断，再用 controller-event 驱动它。这就是"传感器 + 平台 + 通断器"的标准联动链路。

def on_sensor_event(client, event: dict):
"""传感器事件统一入口：event 里是同平台内的设备数据"""
if event.get("type") == "water_leak" and event.get("value") == 1:
set_power(client, False, int(time.time())) # 漏水→立即切断加热设备
alert("水浸触发，已切断热水器供电")
if event.get("type") == "temperature" and event.get("value") > 30:
set_power(client, True, int(time.time())) # 过热→开通风/除湿

联动设计三原则：① 安全类联动（水浸、烟雾）取"失效安全"——失联/异常即断电；② 舒适类联动（温湿度）取"温和策略"——加去抖、加时间窗，避免设备频繁启停（同时照顾 5 万次电气寿命）；③ 人机冲突处理——手动操作优先级高于自动，自动规则要有"手动覆盖"入口。

⚠️ 全章安全再强调：本章所有"自动断电"都是软件层保护，它建立在"平台在线 + 网络通畅"的前提下。真正的电气安全仍由空开、漏保、热继电器等硬件保障。软件保护是"锦上添花"，硬件保护是"保命底线"。

本章要点 / 落地清单

• 定时 = 平台调度下发 controller-event + 设备 device-timer-interval 上报做闭环；
• 过载/异常保护只能在平台侧实现（设备无原生阈值指令），阈值留余量、动作去抖、结果留痕；
• 无人值守重启首选"断电 N 秒再上电"，慎用 controller-reset；
• 传感器联动中安全类取"失效安全"，舒适类取"温和策略"；
• 软件保护 ≠ 电气保护，硬件保护永远是第一道防线。

第 11 章 安装与施工：25A 是"电工活"

一句话点题：25A/6000W 已经进入"必须持证电工、必须按规范接线"的工程范畴，本章给出从选位、接线、负载匹配到保护配合、批量验收的完整施工口径。

11.1 安装形态与位置（接线式、配电箱内/设备旁、散热与空间）

GSCW1M2P 是接线式设备（不是插头式），进出线都要用导线压接端子。物理尺寸 50mm × 110mm × 32mm，外壳阻燃 V0 级，适合两种安装位置：

• 配电箱内（DIN 导轨区或箱内空位）：美观、集中、便于统一保护，适合批量、多回路场景。注意箱内预留走线空间，设备两侧各留 ≥30mm 便于接线与散热。
• 设备旁（就近安装）：适合"只改一台设备"的场景，减少长距离大电流走线损耗。

散热与空间要点：设备待机功率 < 4W，自身发热很小，但端子与导线在大电流下会发热。因此：① 不要把它密贴在其他发热元件旁；② 箱内保持通风，环境温度不宜长期高于 40℃；③ 导线弯折半径要足，避免端子受力。绝对禁止：装在潮湿、淋水、易燃、有腐蚀性气体或儿童可触及的位置。

11.2 接线规范：进线/出线、导线线径与 25A 匹配、端子压接、绝缘与固定

这是全章最需要"照做"的部分。

① 拓扑：市电进线（L、N）→ 空开/漏保 → 通断器进线端 → 通断器出线端 → 负载。设备为单路，只控一根线（L 或 N），一路一个回路，不要试图接成多路。

② 线径：工作电流 25A，导线线径必须与之匹配。参考：≥4mm² 铜芯（长距离、高温、长时间满载建议上到 6mm²）。线径偏小 → 压降大、发热、绝缘老化，是火灾隐患。

③ 端子压接：多股软线必须用冷压端子（线鼻）压接后再插入端子，禁止"裸铜丝直接拧"。压接要牢，插入后逐一拧紧力矩到位，轻拉不脱。

④ 绝缘与固定：接线完成后恢复绝缘护套，裸露导体不得外露；设备用导轨或螺钉固定牢固，导线用扎带整理，避免端子长期受拉扯。

⑤ 相/零与接地：进线分清火线（L）与零线（N），不要把相零接反；负载金属外壳必须可靠接地（PE）。设备外壳虽为 V0 级阻燃，但接地是人身安全的最后一道保障。

┌──────────── L(火) ────┐
市电 ───┤ ├─ 空开 ─[进线] 通断器 [出线]─ 负载
└──────────── N(零) ─────┘ │
PE(地)—┴— 负载外壳接地

⚠️ 施工铁律：断电→验电→挂牌→接线→复检→送电。断电后用验电笔确认无电；接线全程一人操作一人监护；严禁带电接线。多回路作业时，每个回路单独挂牌、单独验电，避免"以为断了其实没断"的致命疏忽。

11.3 负载匹配：阻性 6000W 上限；感性负载降额与接触器方案

设备标注 MAX 6000W（阻性负载）、工作电流 25A。选型务必分清负载性质：

• 阻性负载（热水器、电暖、白炽/卤素灯、加热管）：功率因数为 1，可直接接入。但仍建议留 20%~30% 余量——按现场电压核算（220V 下 25A ≈ 5500W），工程上单路阻性负载建议 ≤ 5000W 更稳妥，把 6000W 当作"上限"而非"常态"。
• 感性负载（电机、压缩机、水泵、风扇）：启动电流可达额定 3~8 倍，25A 触点会被启动浪涌反复冲击，必须降额：电机类负载功率建议控制在额定 25A 的 1/3~1/2，且优先用接触器扩流——让 GSCW1M2P 去驱动接触器线圈，由接触器大触点去切电机主回路。
• 容性/非线性负载（有整流、变频、LED 驱动）：功率因数低，power（视在）会明显大于有功，且浪涌大，同样建议降额或加接触器。

接触器方案（感性负载标准做法）：

市电 ─ 空开 ─┬─ 通断器 ─ 接触器线圈(A1/A2)
└─ 接触器主触点 ─ 电机/水泵等感性负载

这样通断器只承担很小的线圈电流，感性大电流由接触器承担，既保护设备触点寿命，又保证启动可靠。

11.4 保护配合：空开、漏保、浪涌

这是 25A 场景的生命线，软件保护无法替代。 建议三道硬件保护层层配合：

配合原则：① 保护器的额定电流 ≤ 导线载流量，且 ≤ 通断器耐受能力；② 空开跳闸电流要大于设备正常启动电流、小于短路电流；③ 漏保与空开可组合成"漏电断路器"。先硬件保护、后软件保护，顺序不能颠倒。

11.5 批量施工流程（含可打印工序卡）与验收要点

批量施工六步：① 现场勘查（回路、功率、线径、位置）；② 出接线图与材料清单；③ 停电、验电、挂牌；④ 按工序卡逐台接线、固定；⑤ 单台通电自检（配网、MQTT 连接、上报正常）；⑥ 整批联调与验收。

可打印工序卡（每回路一张）：

┌───────────────────────────────────────────────┐
│ GSCW1M2P 施工工序卡 回路编号：______ │
├───────────────────────────────────────────────┤
│ 1. 负载名称/功率/性质(阻性/感性)：____________ │
│ 2. 导线线径：____mm² 空开：____A 漏保：有/无 │
│ 3. [ ] 已断电 [ ] 已验电 [ ] 已挂牌 │
│ 4. 进线端 L/N 接线牢固 [ ] │
│ 5. 出线端至负载接线牢固 [ ] │
│ 6. 端子压接(冷压端子)到位，力矩到位 [ ] │
│ 7. 接地/绝缘恢复 [ ] 设备固定牢固 [ ] │
│ 8. 通电自检：配网[ ] MQTT连接[ ] 上报[ ] 通断[ ] │
│ 9. 用电采集读数：V___ A___ W___ kWh___ │
│ 10. 施工人：____ 监护：____ 日期：____ │
└───────────────────────────────────────────────┘

验收要点：① 逐台核对线径、空开、漏保与负载匹配；② 现场触发一次通断，确认继电动作与 onState 回显一致；③ 查看 info-statistic 读数是否合理（电压接近市电、电流与负载相符）；④ 确认 info-protocol 的 publish/subcribe 与平台配置一致（这两个字段极易搞反：publish 是设备"发布"，平台要订阅；subcribe 是设备"订阅"，平台要发布指令）；⑤ 拍照留档，出具验收单。

本章要点 / 落地清单

• 接线式安装，必须断电验电挂牌、持证电工操作；
• 线径 ≥4mm² 铜芯（长距离/满载考虑 6mm²），端子必须冷压压接；
• 阻性按 ≤5000W 设计（6000W 是上限），感性必须降额 + 接触器；
• 空开（C25/C32）+ 漏保（30mA）+ SPD 三道硬件保护缺一不可；
• 批量施工用工序卡逐台签认，验收核对 publish/subcribe 字段方向。

第 12 章 与配电系统/工业设备对接

一句话点题：GSCW1M2P 是"单相、单路、智能"的一颗执行钉子，本章讲清它如何嵌入配电箱回路、如何借接触器放大、以及和工业控制系统对接时的边界。

12.1 在配电箱中的位置与回路划分

配电箱里，GSCW1M2P 一般放在"支路"层级：总开关 → 分支路空开/漏保 → 通断器 → 单个负载。它不承担总开关职责，一个回路配一个通断器，把需要"独立控制 + 用电计量"的负载单独成路。

回路划分原则：① 大功率、需定时/远程控制的设备（热水器、水泵、空调）单独成路；② 安全相关设备（漏水保护、消防联动的非关键负载）可单独成路；③ 不要把一个通断器串在多个负载前面（会同时通断、也无法分辨各自用电量）；④ 回路命名要清晰，与平台的设备台账一一对应。

一个例子：一间小商铺的配电箱，总开 → 照明支路、插座支路、空调支路（串 GSCW1M2P + 接触器）、热水器支路（串 GSCW1M2P）。这样照明插座照旧，空调与热水器各自可远程控制、各自可查电量，互不干扰。

12.2 用接触器/中间继电器扩展到大电流或多设备

单路 25A 不够用怎么办？用接触器/中间继电器"扩流"或"扩路"，通断器退居"控制信号源"：

• 扩流（大电流负载）：通断器驱动接触器线圈，接触器主触点承载大电流 → 等效支持远超 25A 的负载。
• 扩路（多个小负载同开同关）：通断器驱动中间继电器，由继电器触点去控制多个接触器/负载，实现"一控多"。
• 信号隔离：接触器/中间继电器天然实现"弱控强、小控大"的隔离，提升系统安全性。

平台 ──MQTT── GSCW1M2P(通断器) ── 接触器/中间继电器 ── 大电流或多路负载

注意：接触器线圈是感性负载，通断器驱动线圈时同样要关注线圈功率与浪涌（可选带续流/RC 吸收的线圈回路）。增加接触器后，"用电采集"测到的是通断器所在回路的电参量，若大负载挂在接触器主回路上，采集读数未必等于负载真实功率，需按接线拓扑区分。

12.3 与工业控制（PLC/RS-485/干接点）协同

边界必须说清：GSCW1M2P 没有 RS-485、没有红外遥控，它只有 2.4GHz WiFi（支持 MQTT / TCP / HTTP）。因此它不是工业现场总线设备，对接工业控制要走"网关/平台"这条路：

结论：把 GSCW1M2P 当作"工业系统的智能执行末端"，上层用网关/平台做协议转换，而不是指望它直接说 RS-485。

协同的一个典型闭环：PLC 控制产线需要"某工位设备下班后断电省电"，可让 PLC 通过网关向平台发一条"工位待机"信号，平台再向对应通断器下发 controller-event key=0；设备实际 onState 与用电读数又经 publish 主题回流到平台、再转发给 PLC 做状态确认。信号走"平台"这条软总线，而非设备直连工业总线，这才是本型号在工业场景下的正确用法。

12.4 与既有 200V/380V 系统的边界与注意（本设备为单相 110~260Vac）

这是致命的边界问题，务必牢记： 本设备输入是 110Vac ~ 260Vac 单相，因此：

• ✅ 可用于 单相 220V 系统（含 220V 单相负载）；
• ❌ 不能直接用于 380V 三相 或任何相电压超过 260V 的回路；
• ❌ 不能用它去切三相负载的任何一相"当总控"（三相设备的通断必须用三相接触器/三相断路器，且要保证缺相安全）；
• ⚠️ 若现场是三相四线系统，只取"一相线 + 零线"（相电压 220V）控制单相负载，且要保证相序、中性线可靠，避免"用一相控三相"的错误接线。

边界落地方案：需要控制三相/大功率负载时，用三相接触器做执行，GSCW1M2P 只负责驱动其单相控制线圈（线圈供电取自单相 220V），这样既遵守了设备的 110~260Vac 输入边界，又实现了三相回路的智能控制。

本章要点 / 落地清单

• 定位在配电箱支路级，一个回路一个通断器，不要一控多路混接；
• 扩流/扩路靠接触器/中间继电器，通断器退居控制信号源；
• 没有 RS-485/红外，工业对接必须经网关/平台转协议；
• 只支持 单相 110~260Vac，严禁接 380V 或控制三相负载的一相；
• 三相/大电流场景：三相接触器执行 + 通断器驱动其单相线圈。

第 13 章 应用场景 12 例

一句话点题：下面 12 个场景覆盖家用、商用、工业、农业四大类，统一按「场景与痛点 → 方案设计 → 设备与回路规划 → 关键代码/配置要点 → 价值与收益」展开；所有金额均为示例测算，用于说明量级而非承诺。

统一代码基础（后文按需引用）：set_power(client, on, seq) 下发 controller-event；set_report_interval(client, enable, sec) 下发 device-timer-interval；平台订阅设备 publish 主题收数据、向设备 subcribe 主题发指令。字段严格取自指令表。

场景 1：家用中央空调 / 多联机

场景与痛点：别墅/大平层常用一台外机（多联机）拖多台内机，外机常年待机有电，回家前想提前制冷/制热，又怕长期带电白耗电、雷雨天想彻底断电。

方案设计：GSCW1M2P 串入外机供电回路（单相 220V），实现"到家前 20 分钟远程开机、离家自动断外机、雷雨天一键断电"。

设备与回路规划：外机功率通常较大且含压缩机（感性），25A 裕量有限，强烈建议用接触器扩流——通断器驱动接触器线圈，接触器主触点带外机。回路单独成路，配 C32 空开 + 漏保。

关键代码/配置要点：定时策略 + 用电采集。

# 提前 20 分钟开机，晚上 22:30 断电
def ac_schedule(client):
set_report_interval(client, True, 120) # 每 2 分钟上报一次用电
set_power(client, True, 1001) # 到点开机
# 收到 device-timer-task 后判断功率是否正常（压缩机是否启动）

power 明显偏低可能是压缩机未启动或故障，可作为运维告警依据。

价值与收益：离家彻底断外机，消除待机耗电与雷击风险；到家即享舒适温度。（示例测算：外机待机若按 20W、每天 20 小时无人时段计，一年省电近 150kWh。）

场景 2：商用中央空调（写字楼/商铺）

场景与痛点：商铺空调"下班忘关"浪费大，营业前需提前预冷/预热，多台空调需统一管控。

方案设计：空调主机供电回路接一台（或每台一台）GSCW1M2P，平台按营业时间表自动通断，并统计各区用电。

设备与回路规划：中央空调含压缩机，属感性负载，使用接触器扩流。一个回路一个通断器，按"主机 / 分区"划分，避免一控多机。

关键代码/配置要点：

# 营业前 30 分钟开、打烊后 30 分钟关
def shop_schedule(client, open_h, close_h):
set_report_interval(client, True, 300) # 5 分钟上报
# 平台调度器在 open_h 下发 key=1，close_h 下发 key=0

配合 setting-on-state onState:0（记忆），保证意外断电恢复后按原状态继续。

价值与收益：杜绝"忘关空调"，按营业时段精准供能；用电数据支撑分店铺能效考核。（示例测算：单店每月减少无效运行 40 小时、按 3kW 计可省约 120kWh。）

场景 3：储水式热水器

场景与痛点：储水热水器 24 小时保温持续耗电，长时间不在家还带电有安全隐患。

方案设计：典型阻性负载，直接接入通断器，做"定时加热 + 保温到位即停 + 出门断电"。

设备与回路规划：常见 1500~3000W（阻性），在 25A/6000W 上限内可直接接入；配 C16~C20 空开，必须加 30mA 漏保（人身安全关键）。

关键代码/配置要点：

# 早 6:30 加热，8:00 兜底断；晚 18:00 加热，21:00 兜底断
def heater_schedule(client):
set_report_interval(client, True, 60)
# 平台在加热窗口下发 key=1，窗口结束下发 key=0
# 依据 device-timer-task 的 power 判断是否已到保温

energy 累计值可做"每日耗电"看板。

价值与收益：把"全天保温"改成"按需加热"，避免反复保温耗电；出门断电消除带电隐患。（示例测算：2kW 热水器每天少保温 8 小时，一天省约 16kWh。）

场景 4：即热式热水器

场景与痛点：即热式功率大（常 6~8kW），想做到"用时才通电、防干烧/防忘关"，同时关注线路承载。

方案设计：接入通断器做"用水前通电、用完断电"，并与用水传感器联动。

设备与回路规划：⚠️ 即热式常达 6~8kW，已触及甚至超过 6000W 阻性上限。单台即热式不建议直接接入 25A 通断器；应用接触器扩流，通断器只控接触器线圈；回路用 ≥6mm² 铜芯 + C32/C40 空开 + 漏保。

关键代码/配置要点：

# 与人体/用水信号联动：有人用→key=1，无人 15 分钟→key=0
def instant_heater(client):
set_report_interval(client, True, 30) # 高频上报以防异常
# 平台侧：power > 5000W 持续告警，接近上限立即断电并提示核查

价值与收益：杜绝"忘了关"的持续满功率运行（8kW 忘关 1 小时 = 8kWh）；软硬保护配合降低大功率风险。

场景 5：地暖 / 电暖

场景与痛点：电地暖/电暖器按季使用，需要分时分区控温；长期空置房不想持续采暖。

方案设计：按区域回路接通断器，平台按作息/气温自动通断，空置房可整体断电。

设备与回路规划：阻性负载，单路按 ≤5000W 设计（超限则分区或加接触器）。回路多时"一区一台"，配 C20~C25 空开。

关键代码/配置要点：

# 分时段：夜间低谷电价时段多开，白天少开
def floor_heating(client):
set_report_interval(client, True, 300)
# 平台结合气温传感器：低于阈值 key=1；空置模式 key=0
# energy 统计用于按房间分摊电费

价值与收益：错峰用电 + 分区控制，降低取暖电费；空置房一键断电。（示例测算：错峰利用谷电，取暖季电费可降 15%~20%。）

场景 6：实验室大型仪器

场景与痛点：实验室仪器需"预约使用时间供电、用完断电"，防止下班后忘记关机长时间空转，也想统计各台仪器用电。

方案设计：每台大功率仪器供电回路接通断器，平台按预约时段通断并记录用电。

设备与回路规划：视仪器而定——纯加热/恒温箱类为阻性，可直接接入；含压缩机/电机的仪器按感性处理并评估浪涌，必要时加接触器。强烈建议加漏保。

关键代码/配置要点：

# 预约时段供电：开始 key=1，结束 key=0；无人 30 分钟强制断
def lab_instrument(client, start_ts, end_ts):
set_report_interval(client, True, 60)
# 采集 energy 用于仪器用电台账与成本分摊

价值与收益：杜绝仪器空转，延长设备寿命；用电可计量、可分摊；下班强制断电提升实验室安全。

场景 7：机房 / 弱电间设备

场景与痛点：机房内部分设备（如备用空调、测试机、除湿机、非关键网络设备）偶发死机需现场重启；也希望对非关键负载远程断电。

方案设计：把允许断电的非关键设备供电话接通断器，实现远程断电重启与用电监测。

设备与回路规划：⚠️ 关键设备（核心交换机、主服务器、存储）绝不能串在通断器后硬切；只接"可意外断电"的负载。回路单独成路，配空开+漏保。

关键代码/配置要点：

# 死机远程重启：断电 20 秒再上电
def reboot_box(client):
remote_reboot_downstream(client, off_seconds=20)
# 采集 power 判断设备是否在线（功率骤降可能是宕机）

价值与收益：非关键设备免跑现场重启，降低运维响应时间；机房用电可视化。（示例测算：一次上门重启成本按 200 元计，一月省两次即回本。）

场景 8：充电桩

场景与痛点：私家/园区充电桩需"预约充电、低谷电价充电、空闲断电、异常断电"。

方案设计：充电桩供电回路串入通断器，平台按预约与电价时段通断，并结合用电采集做"充满即停"。

设备与回路规划：⚠️ 单相 7kW 桩超过 6000W 上限，必须接触器扩流或仅控制桩的"控制回路"；回路用 ≥6mm² + C32/C40 空开 + 漏保。充电桩涉及人身与高压安全，务必专业施工并遵循桩厂规范。

关键代码/配置要点：

# 夜间低谷时段供电充电，白天断电
def ev_charger(client, cheap_start, cheap_end):
set_report_interval(client, True, 60)
# power 持续低位=可能已充满，平台可 key=0 停止

价值与收益：低谷电价充电省电费、充满自动停避免过充风险；用电量可计量结算。

场景 9：电动车棚（集中充电）

场景与痛点：车棚多插座、充电器混杂，存在过载、长时间充电、火灾隐患；需要统一时段供电。

方案设计：用一台通断器控制"车棚充电回路总闸"（配合接触器扩流），平台定时"开放充电时段"，其余时间断电；结合用电告警防过载。

设备与回路规划：车棚插座众多、功率叠加，必须经接触器（总电流远超 25A）；回路配足够容量空开 + 30mA 漏保 + SPD（户外雷击防护），导线 ≥4mm²（按总电流加大）。

关键代码/配置要点：

# 白天 8:00-22:00 开放充电，夜间断电（防夜间无人值守充电火灾）
def bike_shed(client):
set_report_interval(client, True, 60)
# power/current 越界 → key=0 并告警

价值与收益：夜间无人时切断充电回路，大幅降低火灾风险；集中时段管理、用电可统计。（安全收益 > 电费收益。）

场景 10：农业灌溉水泵

场景与痛点：农田水泵常需"定时/按需抽水"，人工跑去合闸费时费力；水泵是感性负载，启动冲击大。

方案设计：水泵供电回路接通断器，平台定时或按土壤湿度/水位联动启停。

设备与回路规划：⚠️ 水泵感性、启动电流大，必须降额 + 接触器扩流（通断器只控接触器线圈）；户外配 SPD 浪涌保护 + 漏保，导线按水泵电流选型。

关键代码/配置要点：

# 定时灌溉：到点 key=1，抽够时长 key=0
def pump_schedule(client, run_minutes):
set_report_interval(client, True, 120)
# 结合水位/湿度传感器：缺水 key=1，到位 key=0

价值与收益：免去人工奔波合闸，按需灌溉节水节电；接触器方案保障启动可靠、保护触点。

场景 11：温室大棚设备

场景与痛点：大棚的加热、补光、风机、卷帘等设备需按温湿度自动运行，冬季夜间也要运行，人工值守成本高。

方案设计：按设备分回路接通断器，平台依据温湿度传感器自动通断，并做夜间/白天不同策略。

设备与回路规划：加热/补光为阻性可直接接入（≤5000W/路）；风机为感性需降额+接触器。户外大棚配 SPD + 漏保，导线防潮处理。

关键代码/配置要点：

# 温度低于阈值开加热、高于阈值停；光照不足开补光
def greenhouse(client, temp_threshold):
set_report_interval(client, True, 300)
# on_sensor_event() 里依据 temperature 触发 set_power

价值与收益：温度光照自动调节，作物更稳产；减少人工值守；户外防雷降低设备损坏率。

场景 12：养殖场设备

场景与痛点：养殖场的通风风机、加热保温、照明、投喂设备需要稳定按时运行，且现场环境恶劣（潮湿、氨气、粉尘），对可靠性与安全要求高。

方案设计：分设备回路接通断器，平台按"养殖作息 + 环境参数"自动通断，异常立即断电告警。

设备与回路规划：风机为感性必须降额+接触器；加热灯为阻性可直接接；回路统一加漏保 + SPD；设备防护与走线要防潮防腐。

关键代码/配置要点：

# 高温时段强制通风、低温时段保温，异常断电告警
def farm_control(client, temp_high, temp_low):
set_report_interval(client, True, 120)
# power 越界 / 断电后仍有电流 → 立即告警（现场环境易致继电器异常）

价值与收益：通风保温自动运行，降低畜禽应激与死亡风险；异常自动断电减少事故；用电可量化管理。（对养殖业而言，稳定运行的价值远高于设备本身成本。）

本章要点 / 落地清单

• 12 个场景统一遵循"痛点→方案→回路→代码→收益"五段式；
• 阻性可直连、感性必降额 + 接触器是贯穿 12 例的红线；
• 大功率场景（即热式、充电桩、车棚、水泵）优先接触器扩流；
• 所有场景都要断电作业、配空开/漏保，户外加 SPD；
• 代码字段只用真实指令（controller-event / device-timer-interval / controller-restart 等），不臆造。

第三部分总纲：三条贯穿全篇的红线

第四部分：场景下篇、省钱账与商用运维

本篇是《GSCW1M2P 智能通断器 25A-S2 Plus-WiFi 开发与落地指南》的收官部分。第 14 章承接第 13 章，再给出 12 个商用/工业场景（编号 13~24）；第 15~17 章分别从省钱（成本）、增效（自动化收益）、增收（商业模式） 三个角度，把一台通断器的价值算清楚；第 18~19 章是集成商视角的落地方法论与运维体系；第 20 章是可直接打印使用的附录。

贯穿红线（与前文一致，务必牢记）：① 本设备是接线式安装，必须断电作业、持证电工操作；② 25A / MAX 6000W 是"阻性负载"上限，感性负载（电机、压缩机、水泵、空压机）启动电流可达额定数倍，必须降额并加接触器/软启动；③ 导线线径须与 25A 匹配（参考 ≥4mm² 铜芯，具体以现场电气规范为准），并配容量足够的空开/漏保（户外加 SPD）；④ 它是单路通断器，一路一个回路；⑤ 电气寿命仅 5 万次，高频通断场景务必算寿命账。文中所有金额、节能量均为"示例测算"，用于说明量级而非承诺，读者可按自己的实测参数替换假设与算式。

第 14 章 应用场景 12 例（编号 13~24）

一句话点题：上一章的 12 个场景偏"家庭/农业"，本章的 12 个场景全部落在商铺、工业、市政与无人值守设备上——它们对"大功率、长时间运行、远程运维、电费敏感"的需求更强烈，也更能体现 25A 通断器的价值。每个场景仍按「场景与痛点 → 方案设计 → 设备与回路规划 → 关键代码/配置要点 → 价值与收益」五段式展开。

统一代码基础（后文按需引用，字段严格取自指令表）：set_power(client, on, seq) 下发 controller-event（key:0 断电 / key:1 通电）；set_report_interval(client, enable, sec) 下发 device-timer-interval（timerInterval 5~86400 秒）；remote_reboot_downstream(client, off_seconds) 断电 N 秒再上电实现下游冷启动；平台订阅设备 info-protocol 返回的 publish 主题收数据、向 subcribe 主题发布指令（两个字段方向极易搞反）。数据侧依赖 info-statistic / device-timer-task 上报的 voltage / current / power / energy。

场景 13：商铺照明总控

场景与痛点：商铺、连锁门店照明回路多（主灯、橱窗、后仓、门头），营业/打烊全靠人工拉闸，“忘关灯长明” 与 “开门了灯还没开” 同时存在；连锁品牌还想统一管几十上百家店。

方案设计：把门店照明总回路（或分区回路）串入 GSCW1M2P，平台按营业时间表自动通断，配光感/人体感应做白天补光、无人灭灯；总部后台一键批量下发。

设备与回路规划：门店照明多为 LED（非线性负载），功率因数低、power（视在）明显大于有功，按视在功率选型并留 20%~30% 余量，单路照明建议 ≤5000W。总回路电流超 25A 时用接触器扩流；分区则"一区一台通断器"，配 C25 空开 + 30mA 漏保。回路命名与门店台账一一对应。

关键代码/配置要点：

# 营业 9:00 开灯、22:00 关灯；每 5 分钟上报一次用电
def shop_lighting(client):
set_report_interval(client, True, 300)
# 平台调度器：open 时下发 key=1，close 时下发 key=0
# 收到 device-timer-task 后，energy 累计值写入"门店照明用电日看板"
# 总部批量：遍历门店列表统一 set_power，单店异常（power 长时间为 0 但应亮）告警

价值与收益：杜绝长明、按需照明，直接降低照明电费；连锁门店"一次配置、全网生效"，管理成本骤降。（示例测算：单店照明 1.5kW、每天少亮 4 小时，一年省约 2190kWh，按 0.8 元/kWh 约 1750 元。）

场景 14：广告灯箱

场景与痛点：沿街门头灯箱、候车亭广告灯箱多为夜间点亮，靠时控器或人工，白天长明、半夜不关、雷雨天不敢断电；户外灯箱受雷击浪涌威胁。

方案设计：灯箱供电回路串入 GSCW1M2P，做 “日落开、深夜关”（如 18:00 开、23:30 关），并采集耗电；户外回路加 SPD。

设备与回路规划：LED 灯箱通常几百 W，可直接接入；若单回路汇接多组灯箱、电流接近 25A，用接触器扩流。户外必须配 SPD 浪涌保护 + 30mA 漏保，导线做防水处理。

关键代码/配置要点：

# 日落开、深夜关；故障（应亮却 power≈0）告警
def lightbox(client, on_h=18, off_h=23.5):
set_report_interval(client, True, 600) # 灯箱变化慢，10 分钟一次即可
# 平台按经纬度/季节微调 on_h/off_h
# energy 累加用于广告位电费核算或对外结算

价值与收益：按需点亮消除白天/后半夜长明；商用灯箱可按用电量向广告主结算。（示例测算：0.4kW 灯箱每天少亮 6 小时，一年省约 876kWh。）

场景 15：户外大屏 / 会议大屏

场景与痛点：商场户外 LED 大屏、会议室拼接大屏待机也耗电，会议前要提前预热、散会后常忘关；户外大屏雷雨季需彻底断电。

方案设计：把大屏主供电回路串入通断器，按排期/预约供电；无排期时段彻底断电；与中控联动"开会即通电"。

设备与回路规划：大屏功率常达数 kW，且是非线性负载、浪涌大，建议用接触器扩流——通断器只控接触器线圈；回路用 ≥6mm² 铜芯 + C32 空开 + 漏保，户外加 SPD。

关键代码/配置要点：

# 预约供电：会议开始前 15 分钟 key=1，结束 key=0
def screen_schedule(client, start_ts, end_ts):
set_report_interval(client, True, 120)
# 依据 power：断电后若 power 仍 > 阈值 → 告警（大屏未真正下电）

价值与收益：消除大屏长时间待机耗电，延长屏体寿命；户外屏可远程一键断电避雷。（示例测算：大屏待机 150W、每天 16 小时无人时段，一年省约 876kWh。）

场景 16：工厂产线设备

场景与痛点：产线测试台、包装机、辅助设备下班后常"忘记关机"空转；夜班/白班切换靠人工合闸；设备偶发死机要派人重启。

方案设计：按"设备/工位"分回路接通断器，平台按班次表供电，实现"上班自动上电、下班自动断电"；配合 remote_reboot_downstream 做远程重启。

设备与回路规划：产线设备多含电机（感性），必须降额 + 接触器扩流，通断器只控接触器线圈或设备控制回路。⚠️ 不要用它直接切产线主电源；单独成路、配 C32 空开 + 漏保。

关键代码/配置要点：

def line_shift(client, shift_on, shift_off):
set_report_interval(client, True, 60)
# 班次调度：shift_on 时 key=1，shift_off 时 key=0
def line_reboot(client):
remote_reboot_downstream(client, off_seconds=20) # 死机远程重启

价值与收益：消除班后空转耗电；远程重启缩短停机时间。（示例测算：一次现场重启综合成本约 200 元，每月减少 3 次即年省约 7200 元。）

场景 17：空压机

场景与痛点：空压机是工厂"电老虎"，非生产时段仍保压待机、管网泄漏持续耗电；人工在下班后关空压机不现实。

方案设计：空压机控制回路（或经接触器的主回路）接通断器，平台在非生产时段/夜间自动停空压机，生产前提前开机保压。

设备与回路规划：⚠️ 空压机属大功率感性负载、启动电流极大，严禁用 25A 触点直切主回路；标准做法是通断器驱动接触器线圈，由接触器切空压机主回路；或用通断器控空压机就地控制回路。回路单独成路、配专用空开。

关键代码/配置要点：

# 生产时段 8:00-20:00 允许运行，其余时间停机；提前 30 分钟开机保压
def air_compressor(client):
set_report_interval(client, True, 300)
# 平台：非生产时段 key=0；生产前 key=1
# energy 统计空压机日电耗，用于能效考核（kWh/标方气）

价值与收益：切断非生产时段保压与泄漏耗电，节能显著；用电可量化支撑能效管理。（示例测算：空压机 7.5kW，每天少空转 4 小时，一年省约 10950kWh。）

场景 18：工业风机

场景与痛点：车间排风、除尘风机常年运行，非生产时段无人仍空转；粉尘/高温车间还需按环境动态通风。

方案设计：风机回路接通断器，按班次 + 环境传感器（温度/粉尘） 通断，实现"按需通风"。

设备与回路规划：风机为感性负载，降额 + 接触器扩流；单独成路，配 C32 空开 + 漏保。

关键代码/配置要点：

# 班次运行 + 温度越限强通风
def fan_control(client, temp_high):
set_report_interval(client, True, 120)
# on_sensor_event：temperature > temp_high → key=1；恢复正常且非生产 → key=0

价值与收益：非生产时段停风机省电；粉尘/高温环境自动强化通风更安全、更合规。（示例测算：风机 3kW、每天少转 5 小时，一年省约 5475kWh。）

场景 19：地下车库设备

场景与痛点：地下车库排风机、照明长期运行，能耗大；CO 超标才需要强排，平时可降频/停机；人工管理难度大。

方案设计：按"排风机 / 照明"分回路接通断器，平台按时段 + CO/人体感应控制——平时低速或停、CO 超标或有人时启动。

设备与回路规划：排风机为感性，用接触器扩流；照明为 LED（非线性），可分区或总控；车库潮湿，回路加漏保，导线做防潮处理。

关键代码/配置要点：

# CO 超标强排、平时低耗运行
def garage_control(client, co_limit):
set_report_interval(client, True, 180)
# on_sensor_event：CO > co_limit → key=1（强排）；持续低位 → key=0

价值与收益：车库大功率排风"按需运行"，节电可观；照明按时段分组，杜绝长明。（示例测算：排风机 5.5kW、每天少运行 4 小时，一年省约 8030kWh。）

场景 20：路灯 / 园区照明

场景与痛点：园区路灯靠时控器/人工，点灭时间随季节变化难调整，分区控制粗放；故障排查靠巡查。

方案设计：园区路灯按片区回路接通断器，平台按经纬度/季节自动调整开关灯时刻，并监测各片区用电判断"是否真亮"。

设备与回路规划：路灯为 LED/钠灯（非线性），一个片区回路功率可能较大，按总功率选型，超前用接触器扩流；户外回路必须 SPD + 漏保，导线容量按片区总电流放大。

关键代码/配置要点：

# 日落开、日出关（按日月自动调整）
def street_light(client):
set_report_interval(client, True, 600)
# 平台根据经纬度计算日落/日出时刻，定时 key=1 / key=0
# 各片区 energy 对比：某片区耗电骤降 → 可能线路/灯具故障，告警

价值与收益：按需照明 + 精确点灭时刻，节省电费；分区用电监测变"被动巡查"为"主动告警"。（示例测算：某片区 8kW、每天少亮 1 小时，一年省约 2920kWh。）

场景 21：景观亮化

场景与痛点：楼体亮化、喷泉水景、节日灯光夜间运行且模式多变（平日/周末/节假日不同），人工到场切换成本高。

方案设计：亮化分回路接通断器，平台按**"平日/周末/节假日"模式**下发不同通断时段，节假日加时、平日精简。

设备与回路规划：LED 亮化（非线性）可直连；总回路电流大时用接触器扩流。户外/水景回路防水、防雷（SPD）、漏保一个都不能少。

关键代码/配置要点：

# 模式化调度：节假日延长、平日缩短
def nightscape(client, mode):
set_report_interval(client, True, 600)
# mode=holiday → 18:00-24:00；mode=weekday → 18:30-22:30

价值与收益：按需亮化、模式化运行省电；远程一键切换，省去人工到场。（示例测算：亮化 4kW，节假日外每天少亮 1.5 小时，一年省约 2190kWh。）

场景 22：通信基站空调

场景与痛点：基站/机房空调常年制冷、耗电极大，基站无人值守，空调死机需派人上站重启，成本高、响应慢。

方案设计：基站空调供电话接通断器，平台按温度控温、并支持远程重启；配合用电采集做基站能耗监测。

设备与回路规划：空调含压缩机（感性），接触器扩流；回路单独成路，配 C32 空开 + 漏保。

关键代码/配置要点：

def bts_ac(client, temp_high, temp_low):
set_report_interval(client, True, 300)
# 温度 > temp_high → key=1 制冷；< temp_low → key=0；异常 → 远程重启
def bts_ac_reboot(client):
remote_reboot_downstream(client, off_seconds=30) # 空调"卡死"远程重启

价值与收益：按温度精准制冷省电；远程重启替代上站，省时省钱。（示例测算：一次上站综合成本约 300 元，每站每年少跑 6 次即年省约 1800 元/站。）

场景 23：自助售货机

场景与痛点：自助售货机制冷 24 小时运行，夜间/淡季人流少仍满负荷；设备故障需上门，运营成本高。

方案设计：售货机供电回路接通断器，按客流时段分时供电（白天全功率制冷、深夜节能/停机），并支持远程重启与用电统计。

设备与回路规划：售货机含小压缩机（感性），功率通常几百 W，评估启动浪涌后可直连或加小型接触器；单独成路，配 C16 空开 + 30mA 漏保。

关键代码/配置要点：

# 分时制冷 + 远程重启 + 用电统计
def vending(client, day_start=9, night_start=23):
set_report_interval(client, True, 180)
# 深夜低客流时段 key=0（或降为间隔制冷），白天 key=1
# 每台 energy 汇总，评估单机产出/能耗比

价值与收益：深夜节能供电降低电费；远程重启减少上门维护。（示例测算：售货机 300W、每天少运行 6 小时，一年省约 657kWh。）

场景 24：热水工程 / 电锅炉

场景与痛点：酒店、宿舍、工厂的热水工程 / 电锅炉功率大，24 小时加热保温耗电惊人；能否趁谷电加热、白天保温直接决定成本。

方案设计：电锅炉/热水工程加热回路（经接触器）接通断器，平台做 “谷电时段集中加热 + 温度到位即停 + 白天保温”；配合温度传感器闭环。

设备与回路规划：⚠️ 电锅炉为阻性但超大功率（常达数十 kW），远超 25A/6000W，必须用接触器/交流接触器扩流，通断器只控接触器线圈；回路用大截面铜芯 + 专用空开（按锅炉电流）+ 漏保。大功率电锅炉强烈建议与锅炉厂家/专业电气方共同设计。

关键代码/配置要点：

# 谷电时段（如 23:00-7:00）集中加热，白天保温
def water_boiler(client, valley_start, valley_end, temp_target):
set_report_interval(client, True, 120)
# 谷电时段 key=1 加热；温度达 temp_target → key=0；白天仅保温
# energy 统计验证"谷电加热占比"，直接对应电费下降

价值与收益：谷电加热 + 按需供热，电费显著下降；用电数据可核算到"每吨热水电费"。（示例测算：热水工程日均 300kWh，谷电占比提高到 60%、峰谷价差 0.5 元，日省约 90 元、年省约 3.3 万元。）

本章要点 / 落地清单

• 12 个场景全部落在商用/工业/市政，统一五段式；阻性可直连、感性必降额 + 接触器仍是红线；
• 空压机、电锅炉、产线、大屏等大功率/大感性场景必须接触器扩流，严禁 25A 触点直切主回路；
• 户外（灯箱、路灯、亮化、基站）必须 SPD + 漏保，导线容量按总电流放大；
• 商用场景的价值 = 省电费 + 远程运维 + 用电可计量结算；
• 代码字段只用真实指令（controller-event / device-timer-interval / controller-restart / info-statistic），不臆造。

第 15 章 省钱账：一个通断器帮你省了什么

一句话点题：这一章把"值多少钱"算给你看——从硬件成本、电费、人工三条线，最后汇总成一张可以照着填的 ROI 测算表。所有数字均为示例测算，请用你的实测值替换。

15.1 硬件成本对比（自研 vs 采购成品；10A 插座 vs 25A 通断器）

① 自研 vs 采购成品。 很多人第一反应是"我自己用 ESP8266 + 继电器模块 + 互感器搭一个不就完了？"表面 BOM 便宜，但容易漏算隐性成本：

结论：小批量、非核心场景，采购成品更划算——省的是"时间 + 安全 + 可靠性"。自研只在极大规模、有强定制需求时才值得。

② 10A 插座 vs 25A 通断器。 常见的"10A 智能插座"在本场景直接不够用：

结论：只要单路负载可能超过 ~2kW，就应直接选 25A 通断器；用 10A 插座硬接大功率 = 过载起火隐患。（示例测算：一台 3kW 设备接 10A 插座必然跳闸/发热，属于安全事故而非省钱。）

15.2 电费节省（按需供电、消除待机与长明、峰谷错峰）

电费节省来自三类动作：

统一算式（示例测算）：

年省电量(kWh) = 省下的功率(kW) × 每天省下的小时数 × 365
年省电费(元) = 年省电量 × 电价(元/kWh)
错峰收益(元) = 转移电量(kWh) × (峰价 – 谷价)

三类典型收益示例（示例测算，假设电价 0.8 元/kWh）：

说明：上表为示例测算，实际以现场实测功率与当地电价为准；错峰收益受当地峰谷时段与价差影响很大。

15.3 人工与运维节省（远程重启、免现场）

人工节省往往比电费更"立竿见影"，尤其是无人值守设备：

算式：年省人工(元) = 单次上门成本 × 年均减少次数。（示例测算：单次 200 元、每月减少 3 次 = 年省 7200 元。）

15.4 一张 ROI 测算表（给出假设与算式）

假设（请按需替换）：部署 10 台 GSCW1M2P，单台综合落地成本（设备 + 电工 + 辅材）480 元；一次性平台/施工分摊 3000 元；年电费节省 12000 元；年人工节省 6000 元。

算式汇总：

年净收益 S = (电费节省 + 人工节省) – 年运行成本
静态回收期 T = 一次性投入 C0 / 年净收益 S
三年净收益 = S × 3 – C0

再次强调：以上全部为示例测算，替换成你的真实设备数、电价、月节省次数即可得到自己的结论。经验上，大功率 + 无人值守 + 电费敏感的场景回收期普遍在半年以内。

本章要点 / 落地清单

• 采购成品通常比自研更划算——省"时间 + 安全 + 可靠性"；
• 单路 >2kW 就别用 10A 插座，直接上 25A 通断器；
• 省电三条线：按需供电、消除待机/长明、峰谷错峰；
• 人工节省常比电费更快回本（远程重启 = 省一次上门）；
• 所有金额标注"示例测算"，用 S = 电费省 + 人工省 – 运维成本、T = C0 / S 自行测算。

第 16 章 增效：自动化带来的收益

一句话点题：省的是"成本"，增的是"效率与体验"——本章讲通断器带来的四类效率收益：集中管控、用电可视、远程重启、数据驱动。

16.1 大功率设备的集中管控

散落各处的空调、锅炉、水泵、风机，过去是"一人一摊、各管各的"。接入平台后，一个后台管全部：批量下发 controller-event、统一时间表、统一告警策略。对连锁门店/多园区/多机房尤其关键——从"人管设备"变成"系统管设备"。

16.2 用电可视与节能

设备原生上报 voltage / current / power / energy：电压反映供电质量，电流/功率反映负载状态，累计电量支撑分项计量与费用分摊。有了数据，才能发现"哪台设备在悄悄耗电"——没有计量就没有节能。数据可直接做成看板，让节能从口号变成指标。

16.3 远程重启减少停机

现场设备死机，最贵的是"等人工到现场"。用 remote_reboot_downstream（断电 N 秒再上电）把"平均修复时间"从数小时压到数分钟。对基站、机房、售货机、产线辅助设备，"秒级响应"直接换算成减少的业务损失。

16.4 数据驱动

当每台设备都持续上报用电与状态，就能做：① 用电基线，识别异常用电；② 设备健康画像（如 power 长期偏低=效率下降）；③ 分时电价下的用能优化；④ 结合历史数据做预测性维护。数据是自动化的副产品，却是增效的最大资产。

本章要点 / 落地清单

• 集中管控 = 一个后台管全部，从"人管设备"到"系统管设备"；
• 用电可视 = 分项计量 + 分摊，没有计量就没有节能；
• 远程重启 = 把修复时间从小时级压到分钟级；
• 数据驱动 = 基线、异常识别、预测性维护。

第 17 章 增收：把通断器变成商业模式

一句话点题：对集成商与服务商而言，通断器不只是"省电工具"，更是可复制、可订阅、可持续收费的商业载体——本章给出 5 种变现路径。

17.1 系统集成项目

以"大功率设备智能管控"为卖点承接项目：园区照明改造、工厂能效管理、基站/机房运维、连锁门店照明总控……设备是入口，方案与服务才是主体。单项目收入 = 设备 + 施工 + 平台 + 首年服务。

17.2 SaaS 订阅

自建服务器（setting-mqtt / setting-tcp 指向自己的云，与厂商云解耦），把"设备管理 + 数据看板 + 告警 + 报表"打包成 SaaS 按月/按年订阅。设备越多、粘性越强，形成经常性收入（MRR）。

17.3 能耗托管 / 节能分成

"零投入、省下的电费分成"模式：服务商出资部署通断器与平台，用实际计量（energy）核算节能量，与客户按比例分成。省得越多、赚得越多，客户几乎无风险，易成交。

17.4 代运维

把"线上监控 + 远程重启 + 告警响应 + 定期巡检"打包成运维服务费。对无人值守设备（基站、售货机、路灯），客户愿意为"有人兜底、随时响应"付费。

17.5 行业定制

针对垂直行业做定制方案与品牌：农污泵站、养殖环控、光伏配套、充电运营、市政亮化……把通用能力包装成"行业解决方案"，溢价空间大、竞争少。

变现路径速览（示例测算）：

本章要点 / 落地清单

• 设备是入口，方案 + 服务 + 平台才是收费主体；
• 自建服务器解耦，做 SaaS 订阅形成经常性收入；
• 节能分成让客户零投入、你赚节能收益；
• 代运维把无人值守设备的"兜底"变成现金流；
• 行业定制提升溢价与壁垒。

第 18 章 项目管理：集成商视角的落地方法论

一句话点题：好方案能不能变成好项目，靠的是流程——本章给出从勘查、选型、实施到验收的集成商标准动作，特别强调现场电气勘查这道"保命工序"。

18.1 需求调研与方案设计（含现场电气勘查！）

第一步永远是现场勘查，不是先报价。 现场电气勘查清单（断电后逐项确认）：

⚠️ 电气安全红线：勘查必须断电、验电、挂牌；三相/380V 设备超出本设备 110~260Vac 单相边界，禁止直接接入，需另配方案。

方案设计要素：负载匹配（直连/接触器）、回路划分（一路一台）、保护配置（空开/漏保/SPD）、控制策略（定时/传感器/远程）、数据需求（计量/告警）、网络与平台对接。

18.2 选型与 BOM 清单

选型口诀：大功率看电流、感性看浪涌、户外看防护、计量看场景。

标准 BOM 清单（示例）：

18.3 实施计划与里程碑

典型里程碑（示例，周期随项目规模伸缩）：

18.4 验收标准与交付物

验收标准（逐项打勾）：① 线径、空开、漏保与负载匹配；② 触发通断，继电器动作与 onState 回显一致；③ info-statistic 读数合理（电压≈市电、电流与负载相符）；④ info-protocol 的 publish/subcribe 与平台配置一致（极易搞反）；⑤ 告警策略触发正常；⑥ 施工照片与图纸留档。

交付物清单：方案书、BOM、电气接线图、逐台工序卡、联调记录、验收单、设备台账（MAC/位置/回路）、运维手册（含远程重启、改服务器需重启的说明）。

本章要点 / 落地清单

• 先勘查、后报价；含现场电气勘查，断电验电挂牌是前提；
• 选型口诀：大功率看电流、感性看浪涌、户外看防护、计量看场景；
• BOM 六件套：通断器 + 接触器 + 空开 + 漏保 + SPD + 匹配导线；
• 六个里程碑：勘查→设计→进场→施工→联调→验收；
• 交付必须含设备台账 + 接线图 + 验收单，并核对 publish/subcribe 方向。

第 19 章 运维体系：让系统长期稳定

一句话点题：装完只是开始，运维决定系统能不能稳定跑三年——本章讲监控告警、变更管理、故障分级与大规模部署经验。

19.1 监控与告警（在线率、指令成功率、异常用电）

要点：告警要分级 + 去抖 + 留痕，避免"告警风暴"；安全类（漏电、过载）即时推，统计类（用电偏高）日报送。

19.2 固件 / 配置变更（改服务器需重启生效）

关键提醒：用 setting-mqtt / setting-tcp 修改到自建服务器后，必须断电重启或下发 controller-restart 才生效——这是高频踩坑点。变更管理建议：① 变更前记录当前 info-protocol（server/port/publish/subcribe/clientId/username）；② 变更后确认设备已连上新服务器（收到上报）；③ 批量变更分批执行、留回滚方案；④ controller-reset（恢复出厂）会丢配置，慎用。

19.3 故障分级与响应

处置顺序：先硬件保护、后软件排查；P1 类必须以人身与电气安全为第一优先。

19.4 大规模部署（百台/千台）经验与电气寿命管理

百台/千台要点：

寿命算式（示例测算）：若某回路每天动作 20 次，电气寿命 5 万次 → 50000 / 20 / 365 ≈ 6.8 年。若每天 200 次 → 不到 0.7 年，必须降频或改接触器。

本章要点 / 落地清单

• 监控四指标：在线率、指令成功率、异常用电、数据缺失；
• 改服务器必须重启（断电或 controller-restart）才生效，变更前留档；
• 故障分级（P1~P4）+ 响应时限，先硬件安全、后软件排查；
• 千台部署靠台账 + 网络规划 + 批量脚本 + 限速；
• 电气寿命 5 万次要算账：高频场景降频或改接触器。

第 20 章 附录

一句话点题：本章是"随取随用"的速查工具——指令表、代码索引、施工检查清单、FAQ 与结语。

20.1 指令速查表

方向提醒：publish = 设备发布（平台订阅收数据）；subcribe = 设备订阅（平台发布下指令）。字段拼写以固件为准，勿"改对"。

20.2 代码示例索引

20.3 安装施工检查清单（可打印）

┌────────────────────────────────────────────────┐
│ GSCW1M2P 安装施工检查清单 回路：______ │
├────────────────────────────────────────────────┤
│ 【电气安全】 │
│ [ ] 已断电、已验电、已挂牌、一人操作一人监护 │
│ [ ] 由持证电工操作，严禁带电接线 │
│ [ ] 负载性质已确认（阻性/感性/非线性） │
│ [ ] 功率/电流 ≤ 25A、≤6000W(阻性)，感性已降额 │
│ [ ] 三相/380V 未接入（本设备仅 110~260Vac 单相） │
│ [ ] 导线 ≥4mm² 铜芯（满载/长距离 6mm²） │
│ [ ] 端子冷压压接到位、力矩到位、轻拉不脱 │
│ [ ] 空开容量匹配（≤导线载流量）、漏保已装 │
│ [ ] 户外已加 SPD 浪涌保护 │
│ [ ] 接地恢复、绝缘护套恢复、设备固定牢固 │
├────────────────────────────────────────────────┤
│ 【通电自检】 │
│ [ ] 配网成功、2.4GHz WiFi 信号良好 │
│ [ ] MQTT/TCP 连接成功、上报正常 │
│ [ ] 触发通断，动作与 onState 回显一致 │
│ [ ] info-statistic 读数合理（V/A/W/kWh） │
│ [ ] info-protocol 的 publish/subcribe 与平台一致 │
│ [ ] 告警策略触发正常 │
├────────────────────────────────────────────────┤
│ 施工人：______ 监护：______ 日期：______ │
└────────────────────────────────────────────────┘

20.4 常见问题 FAQ

Q1：GSCW1M2P 是插座吗？能直接插设备吗？
A：不是。它是接线式设备，需进线/出线接线，必须由持证电工断电作业。它是单路通断器，一路一个回路。

Q2：25A / 6000W 能带多大设备？
A：25A 是工作电流，MAX 6000W 是"阻性负载"上限。工程上单路阻性建议 ≤5000W（留余量），220V 下 25A≈5500W。

Q3：能带空调、电机、水泵吗？
A：能，但它们是感性负载，启动电流可达额定数倍，必须降额并加接触器——让通断器控接触器线圈，接触器切主回路。

Q4：能带三相 380V 设备吗？
A：不能。本设备输入 110~260Vac 单相，三相/380V 超出边界，需另配方案。

Q5：能测电吗？测的是什么？
A：能。上报 voltage / current / power / energy，其中 power 是视在功率，工程上按需换算有功/电费。

Q6：上报频率怎么设？
A：用 device-timer-interval，timerEnable:1、timerInterval 取 5~86400 秒。

Q7：怎么改成自己的服务器？
A：用 setting-mqtt（MQTT）或 setting-tcp（TCP）指向自建服务器，改后必须断电重启或 controller-restart 才生效。

Q8：publish 和 subcribe 谁订阅谁发布？
A：publish 是设备发布的主题，平台要订阅；subcribe 是设备订阅的主题，平台要往这里发布指令。 极易搞反，务必核对。

Q9：能接入自己的平台吗？有隐性成本吗？
A：可以。支持 MQTT/TCP/HTTP、可指向自建服务器，与厂商云解耦，无捆绑、无隐性成本。

Q10：支持 RS-485 / Modbus 吗？
A：不支持。本型号无 RS-485、无红外遥控；工业对接需经网关转换。

Q11：怎么远程重启下游设备？
A：下发 controller-event key=0，等 10~30 秒再 key=1，下游即冷启动。可与 setting-on-state 配合。

Q12：setting-on-state 三个值什么意思？
A：0 记忆（按断电前状态恢复）、1 关闭、2 开启（来电即工作）。

Q13：设备死机（网络假死）怎么办？
A：下发 controller-restart（system:"restart"）让设备自身重启。

Q14：controller-reset 会造成什么后果？
A：恢复出厂，会丢失所有配置（含服务器设置），慎用。

Q15：设备多久报一次数据？不报怎么办？
A：按 timerInterval 定时上报 device-timer-task；若超 2 倍间隔未收到，平台应告警。

Q16：电气寿命和机械寿命是多少？
A：机械寿命 500 万次，电气寿命 5 万次。高频通断要算寿命账。

Q17：高频通断场景怎么办？
A：降低通断频次、加大去抖时间窗；超高频场景让接触器承担主通断，通断器只做控制。

Q18：能做过载自动跳闸吗？
A：设备无原生阈值跳闸指令；过载/异常保护要在平台侧判断后下发 key=0 实现，且硬件保护（空开/漏保/热继）永远是第一道防线。

Q19：断电后仍有电流怎么回事？
A：可能是继电器粘连或线路异常，属严重问题，应立即人工断电检修并告警。

Q20：导线要多粗？
A：与 25A 匹配，参考 ≥4mm² 铜芯，满载/长距离建议 6mm²，具体以现场电气规范为准。

Q21：需要配空开/漏保吗？
A：必须。空开做过载/短路保护，漏保（30mA）做人身触电保护；户外加 SPD。

Q22：能装户外吗？
A：需防护到位（防水盒、SPD、漏保），避免潮湿/淋水/腐蚀环境；严禁儿童可触及位置。

Q23：待机耗电多少？
A：待机功率 < 4W。

Q24：尺寸多大？好装配电箱吗？
A：50mm × 110mm × 32mm，接线式，适合配电箱内或设备旁，两侧留 ≥30mm 走线散热空间。

Q25：外壳阻燃吗？
A：外壳为阻燃 PC/ABS，V0 级。

Q26：支持 5GHz WiFi 吗？
A：只支持 2.4GHz WiFi。

Q27：怎么清零累计电量？
A：下发 energy-clear。

Q28：按键锁和配网锁有什么用？
A：setting-key-lock（keyLock）锁物理按键防误触；setting-wifi-lock（wifiLock）锁配网防误连。

Q29：一条指令怎么确认执行成功？
A：messageId 为业务流水号，设备原样回显；平台比对回显与响应字段（如 onState）判断结果。

Q30：能一条指令控制多个回路吗？
A：不能。设备是单路，一路一个回路；多回路需多台设备或配接触器。

Q31：设备离线了还能远程控制吗？
A：不能。远程控制依赖网络在线；离线时硬件保护仍在，软件保护失效——这正是硬件保护不可省的原因。

Q32：一个平台能管多少台？
A：取决于你的服务器与 Broker 容量；千台级部署要限速批量下发、分层 Topic、分区网络。

Q33：怎么排查"指令发了没反应"？
A：① 查设备在线率；② 核对 publish/subcribe 方向与平台配置是否一致；③ 查 messageId 是否有回显；④ 检查 WiFi 信号与服务器连通性。

Q34：更换服务器后设备没连上？
A：多半是改完没重启。setting-mqtt/setting-tcp 后需断电重启或 controller-restart，并核对 server/port/publish/subcribe/clientId/username。

Q35：用电数据能用于收费结算吗？
A：可作为参考计量（视在功率/累计电量），正式结算建议以合规电能表为准，并做现场校核。

20.5 结语

从第 1 章的"10A 插座不够用"，到这里 24 个场景、三张价值账（省钱/增效/增收）、两套方法论（项目管理/运维）与一份可直接打印的附录，一台 25A 智能通断器能覆盖的事，已经远超"远程按一下开关"。

它真正的价值，是用很小的代价（一台设备 + 一次断电重启），把大功率设备接入"可控制、可计量、可运维、可结算"的体系。而安全始终是前提：断电作业、持证电工、线径匹配、空开/漏保/SPD 到位、感性负载降额加接触器——这条红线，一分都不能让。

愿你在下一个项目里，把这份文档变成更省的电、更快的响应、更稳的系统、更厚的利润。

全篇落地清单（速览）

• 场景选择：从第 13/14 章 24 个场景中匹配你的业务；
• 安全施工：断电验电挂牌、持证电工、接触器降额、空开/漏保/SPD；
• 协议对接：核对 publish/subcribe 方向，改服务器记得重启；
• 价值测算：用 S = 电费省 + 人工省 – 运维成本、T = C0 / S 算回收期；
• 运维体系：监控四指标 + 故障分级 + 电气寿命管理；
• 商业落地：集成 / SaaS / 节能分成 / 代运维 / 行业定制。

附录 A · 设备规格与指令基准

1. 产品

• 品牌：GemeOpen（武汉智鸟科技）
• 型号：GSCW1M2P，产品名「智能通断器 25A-S2 Plus-WiFi」
• 定位：面向开发者的大功率智能通断器——25A 大电流、最大 6000W，单路接线式安装，带用电采集

参数（以此为准）

能力

• 远程通断电控制（单路继电器）
• 用电采集：电压(V)、电流(A)、视在功率(W)、累计用电量(kWh)
• 电量数据定时上报（可设频率）
• 上电默认状态、按键锁、配网锁、累计电量清零
• MQTT / TCP / HTTP；可接入自建服务器，与厂商云解耦、无捆绑无隐性成本

2. 通信与主题

• 出厂默认连 GemeOpen 厂家 MQTT 测试服务器；可用 setting-mqtt / setting-tcp 改到自建服务器，改后需断电重启或 controller-restart 生效。
• info-protocol 返回字段语义（易错，务必讲清）：
  • publish：设备发布数据的主题 → 平台要订阅
  • subcribe：设备订阅的主题（固件固定拼写，不要"改对"）→ 平台要发布（下指令）
  • 另含 server、port、username、clientId

3. 指令全集（下行为主；messageId 为业务流水号，设备原样回显）

说明：本型号还支持内网 HTTP 控制（HTTP）。字段细节以 GemeOpen 官方开发文档为准；本篇重在讲清"怎么用、在哪用、值多少"。

4. 关键工程约束（必须反复强调，安全相关）

• 接线式安装（非插头）：需进线/出线接线，务必断电作业、由专业电工操作。
• 25A / 最大 6000W 是"阻性负载"上限；感性负载（电机、压缩机、水泵）启动电流可达额定数倍，必须降额并考虑接触器/软启动。
• 导线线径要与 25A 匹配（参考：≥4mm² 铜芯，具体以电气规范为准），并配足够容量的空开/漏保。
• 是单路通断器（不是三路开关），一路一个回路。
• 用电采集上报的是视在功率（工程上按需换算有功/电费）。
• 设备寿命：机械 500 万次、电气 5 万次——高频通断场景请注意寿命预算。