大家好，我是嵌入式学习菌，专注 ESP32 嵌入式实操调试，结合你当前的电表项目（sunshare_ems 相关代码）、FRP 穿透配置及实际网络环境，今天用最通俗的大白话，把「设备开机 → 电表自动换 IP→ 内网穿透转发 → 电表与远程 EMS 通讯」的全流程拆解得明明白白，全程对应你的真实场景，同时解决你遇到的 errno 128 报错问题，看完就能上手调试，彻底搞定跨网通讯难题。
核心亮点：三合一闭环（服务名自动寻址 + 局域网通讯 + FRP 内网穿透），不用改电表代码，仅通过配置和环境搭建，就能实现电表与远程 EMS 的跨网通讯，完美匹配你的项目需求。
一、核心固定信息（你的真实调试环境，必记）
所有流程都基于你当前的硬件、网络配置，不用额外修改，精准对应你的场景：
| 设备/服务 | 核心配置 | 核心作用 |
|---|---|---|
| 电表（ESP32） | 不写死 IP，仅识别服务名「sunshare_ems」，自动寻址 | 采集电压、用电量等数据，接收远程 EMS 指令 |
| 笔记本 | IP=192.168.2.64，与电表连同一 WiFi，运行 FRP 访客客户端 | 搭建穿透隧道，中转电表与远程 EMS 的数据 |
| 远程 EMS 服务器 | 客户现场，拥有公网 IP=182.92.106.122，核心业务服务器 | 接收电表数据，下发控制指令，实现远程管控 |
| 穿透方式 | FRP STCP 安全内网穿透（访客模式） | 加密跨网传输，解决电表与远程 EMS 不在同一网络的通讯问题 |
二、全流程分步拆解（从开机到通讯，每一步都对应你的操作）
整个闭环流程分为 3 步，环环相扣，每一步都能对应你实际调试中的操作和现象，尤其讲清你最关心的「电表 IP 自动变化」的原理：
第一步：笔记本搭建内网穿透隧道（核心前提，穿透的关键）
这一步是跨网通讯的基础，相当于在笔记本和远程 EMS 之间，打通一条"加密数据通道"，具体操作和原理如下：
- 启动笔记本上的 FRP 访客客户端（使用你提供的 FRP 配置文件）；
- FRP 客户端会根据配置，主动发起连接，找到客户现场的远程 EMS 服务器（公网 IP=182.92.106.122，端口=20000）；
- 客户端向远程 EMS 声明身份："我是 ems_visitor（访客客户端），专门对接你的 EMS 服务，负责中转电表数据"；
- 笔记本在本地开启监听：占用自身 IP（192.168.2.64）的 10241 端口，等待电表主动连接；
- 最终结果：笔记本与远程 EMS 之间，建立一条永久、加密的跨网隧道，数据可以双向传输，互不干扰。
⚠️ 重点：这一步必须先做，是后续所有通讯的前提，少了这一步，电表再怎么找地址，也无法实现跨网通讯。
第二步：电表自动寻址，IP 自动更新（你最关心的核心现象）
你看到的「电表 IP 自动变了」，本质是电表的"服务名自动寻址"功能，全程不用手动改电表代码，完全自动完成，具体流程：
- 电表开机后，不会去记任何固定 IP（避免 IP 变动导致通讯失败），只专注一件事：在当前局域网（同一 WiFi）里"广播喊话"；
- 电表广播内容："谁是 sunshare_ems 服务？请告诉我你的地址！"；
- 此时，你的笔记本已经启动了 FRP 客户端，并且已经监听了 192.168.2.64:10241 端口，会立刻回应电表："我就是 sunshare_ems！我的地址是 192.168.2.64:10241"；
- 电表收到回应后，自动更新自身的连接目标：把原来的旧 IP，替换成笔记本的 IP（192.168.2.64）和监听端口（10241）；
- ✅ 原理总结：电表认"服务名"不认"固定 IP"，只要笔记本能回应它的"喊话"，它就会自动对接，这就是 IP 自动变化的核心原因。
第三步：最终通讯闭环（电表 ↔ 笔记本 ↔ 远程 EMS）
隧道建好、电表找到连接入口后，数据就会通过穿透隧道实现跨网传输，这就是完整的业务通讯流程，分为"电表上传数据"和"EMS 下发指令"两个方向，全程自动化：
1. 电表 → 远程 EMS（上传数据）
电表采集到电压、用电量、设备状态等数据后，会主动发送给已经找到的"入口"------笔记本的 192.168.2.64:10241 端口；笔记本通过之前搭建的 FRP 穿透隧道，将数据转发给客户现场的远程 EMS 服务器（182.92.106.122），完成数据上传。
2. 远程 EMS → 电表（下发指令）
远程 EMS 服务器根据业务需求，发送控制指令（比如参数调整、设备重启等）；指令通过 FRP 穿透隧道，传回笔记本的 192.168.2.64:10241 端口；笔记本再将指令转发给电表，电表接收后执行对应操作，完成指令下发。
一句话通俗总结：电表只认 sunshare_ems 服务名，自动找到同 WiFi 的笔记本；笔记本相当于"数据中转站"，通过 FRP 穿透，把电表和千里之外的远程 EMS 连在一起，所有数据都通过这个中转站跨网传输，全程不用改电表一行代码。
三、重点解决：errno 128 报错（你遇到的核心问题）
你之前遇到的「errno 128」报错，不用复杂排查，原因只有一个，解决方案也非常简单：
❌ 报错唯一原因
第一步的「内网穿透隧道没建好」------ 笔记本的 192.168.2.64:10241 端口没有正常监听。
通俗理解：电表已经成功找到笔记本的地址（192.168.2.64），也知道要连接 10241 端口，但它"敲门"的时候，笔记本的这个端口没有打开（FRP 客户端没启动），所以连接被拒绝，触发 errno 128 报错。
✅ 快速修复方法
- 关闭笔记本上的 FRP 客户端（如果已启动，先关闭）；
- 重新启动 FRP 访客客户端，确保配置文件正确（重点核对远程 EMS 的公网 IP、端口，以及自身的监听端口 10241）；
- 启动后，确认笔记本的 192.168.2.64:10241 端口处于正常监听状态（可通过网络工具排查端口是否占用）；
- 重启电表，让电表重新自动寻址，此时电表能正常连接笔记本端口，报错即可解决。
四、实操注意事项（避坑关键）
- 启动顺序不能乱：必须先启动笔记本的 FRP 客户端（搭建隧道），再启动电表，否则电表寻址时找不到对应服务，会一直报错；
- 服务名不能错：电表只认「sunshare_ems」，FRP 客户端配置中必须对应这个服务名，否则无法回应电表的"喊话"；
- 网络要通畅：笔记本和电表必须连同一 WiFi（确保局域网通讯正常），笔记本能正常访问互联网（确保能连接远程 EMS 的公网 IP）；
- 端口不能占用：笔记本的 10241 端口不能被其他软件占用，否则 FRP 客户端无法正常监听，导致穿透隧道搭建失败。
五、总结（核心提炼，快速上手）
这套三合一闭环流程，核心优势就是"不用改电表代码，仅通过配置实现跨网通讯"，完美适配你的项目场景：
- 电表侧：靠服务名自动寻址，解决 IP 变动的痛点，不用手动配置；
- 笔记本侧：运行 FRP 访客客户端，搭建穿透隧道，承担数据中转作用；
- 服务器侧：通过公网 IP 接收数据、下发指令，实现远程管控；
- 报错解决：errno 128 本质是 FRP 未启动、端口未监听，重启 FRP 客户端即可快速修复。
按照这个流程操作，你就能轻松实现电表与远程 EMS 的跨网通讯，后续调试中，只要确保 FRP 隧道正常，电表就能自动完成寻址和数据传输，大幅降低调试难度。
我会持续分享嵌入式实操调试干货，针对你的电表项目，后续还可以补充 FRP 配置文件的详细核对、端口排查技巧，关注我，少踩坑、高效落地项目！