房车计划-改造日志 Vol.6：给房车装上神经系统，电气控制架构搭建
前面几篇日志里，这台图雅诺已经完成了从“空壳货车”到“半成品房车”的几个关键步骤。
车体拆空、除锈、防锈、隔音、保温，副驾下方塞进了 24V 主电池，车内开始有床、有桌板、有水路、有空调、有 220V 插座，也经历了第一次千岛湖露营的实战测试。
第一次露营之后，我很快意识到一件事：
房车不是把一堆设备装进车里就完事了。
电池、空调、水泵、灯光、逆变器、传感器、语音模块、手机控制面板，这些东西如果各自独立运行，短期看能用，但长期一定会乱。
尤其是 Vol.5 里出现过的问题：水路漏水导致 004 节点进水、空调高温保护、BMS 断连、快充补电方案失败，都说明这台车已经不能只靠“开关 + 经验”来管理了。
所以 Vol.6 开始，我要做的是另一件事：
给这台房车装上一套神经系统。
也就是整车的电气控制架构。
![图1：整车电气控制架构总览图]
一、为什么要做控制架构？
传统房车当然也可以全部靠机械开关。
灯光一个开关，水泵一个开关，逆变器一个开关，空调一个遥控器，水位靠肉眼看，电量靠 BMS App 看。这样也不是不能用。
但我的这台车有几个特殊点：
第一，它是自改房车，设备来源很杂。
有 24V 电池，有双向逆变器，有驻车空调，有水泵，有紫外杀菌灯，有灯带，有各种传感器，还有 ESP32 节点。
第二，它不仅要能手动控制，还要能自动化。
比如冷凝器温度太高时自动开辅助风机，睡眠模式下降低灯光亮度，水路异常时关闭水泵，电量过低时关闭非必要负载。
第三，它必须本地可用。
房车很多时候停在山里、湖边、露营地，网络不稳定是常态。不能把控制系统完全依赖云端。
第四，它要方便后续扩展。
今天装水路节点，明天加逆变器节点，后天再加语音控制。如果每次都重新改一遍总线和线束，后期一定会崩。
所以最终确定的方案不是一个“大一统中控板”，而是：
分布式 ESP32 节点 + MQTT 通信 + 本地网页数据面板 + Home Assistant 联动。
简单说：
每个功能区一个节点，各节点负责本地采集和执行，000 主控/数据面板负责汇总展示、下发指令和自动化入口。
![图2：分布式节点与 MQTT 通信示意图]
二、整体架构：不是一个大脑，而是一套神经网络
我一开始也想过做一个“大主控”，所有灯光、水泵、空调、逆变器、传感器都接到一个 ESP32 或一个控制盒里。
但很快发现这种方式不适合房车。
因为房车的设备分布很散：电池在副驾下方，水路在后舱，灯带在睡眠区，空调冷凝器在底盘，逆变器在设备舱，语音模块在前部或生活区。如果全部拉线到一个控制盒，会导致线束又长又乱，检修也很困难。
最终采用的是分布式架构：
各功能节点 ESP32
↓
MQTT
↓
000 主控 / 本地网页面板
↓
Home Assistant / 自动化 / 手机控制 / 语音控制
它的好处很明显：
某个节点坏了，不影响整车其他功能；
新增功能时，只需要新增节点和 MQTT 主题；
强电、弱电、水路、传感器可以按区域分开；
手机、本地网页、语音、实体按键可以共存；
后续自动化逻辑可以逐步增加，不需要一次写完。
这套架构更像一套神经网络，而不是一个单独的大脑。
000 节点负责汇总和交互，但它不是所有设备的唯一生命线。即使 000 掉线，各节点也应该尽量保留本地基础功能。
三、节点规划：每个节点只管自己的一亩三分地
目前整车控制节点按编号规划。
![图3：各 ESP32 节点实物与安装位置]
这个编号体系的好处是清晰。
以后写代码、看日志、看 MQTT 主题，都能一眼知道某个状态来自哪个节点。比如 004 离线，那就是水路控制；006 异常，那就是逆变器/充电控制；008 收到指令，那就是语音入口触发。
四、000 主控：本地数据面板，而不是云端遥控器
000 是整套系统的汇总节点，也可以理解成车内的本地数据面板。
它的任务不是直接接管所有硬件，而是把各个节点的状态集中展示出来，并提供统一控制入口。
目前面板里已经有类似这样的模块：
002 睡眠舱；
003 电力系统；
004 水路控制；
005 移动终端；
后续还会接入 006 逆变器/充电节点和 008 语音节点。
![图4：000 本地网页数据面板截图]
这个面板运行在本地局域网里。车内手机连上 WiFi 后，可以直接打开本地 IP 查看状态和控制设备。
这样做有几个好处：
不依赖公网；
不依赖云平台；
响应速度快；
调试方便；
网络差的地方也能用。
后续 Home Assistant 可以接入，但 Home Assistant 不是唯一入口。我的思路是：
000 是房车本地面板，Home Assistant 是更高级的展示和自动化平台。
如果以后 HA 崩了，或者路由器状态不稳定，至少本地面板和各节点基础功能还在。
五、002 睡眠舱：灯光是最先落地的控制对象
002 节点负责睡眠舱照明。
房车里灯光不是简单地“亮”和“不亮”。晚上睡觉、车内办公、做饭、找东西、夜间起身，每种场景对灯光的需求都不一样。
所以 002 节点规划了几类灯光：
白光；
暖光；
RGB 氛围灯；
亮度调节；
RGB 特效；
后续可接入睡眠模式。
![图5：睡眠舱灯光控制界面]
灯光节点是最适合先做自动化的部分，因为风险相对低。
即使代码有 bug，最多也就是灯没亮、灯太亮、颜色不对，不会像水泵、逆变器、空调那样带来明显安全风险。
所以 002 节点也是整套控制系统的低风险试验田。
通过它可以先验证：
MQTT 指令下发是否稳定；
本地网页滑块控制是否流畅；
ESP32 PWM 调光是否可靠；
节点在线状态是否准确；
手机端操作是否顺手。
等灯光这套跑稳，再把同样的通信逻辑扩展到水路、电力和逆变器上。
六、003 电力系统：车内能源状态必须可见
电力系统是整台房车的心脏。
这台车的主系统是 24V 电池组，前面已经搭建了 8 串磷酸铁锂电池，配合 BMS、逆变器、DC-DC、220V 插座和各种低压负载。
003 节点的目标是让电力系统状态可见。
最基本的状态包括：
SOC；
总电压；
电流；
电池温度；
充放电状态；
关键电源模块状态；
必要时提供 MOS 强制越权入口。
![图6：003 电力系统状态截图]
第一次露营后，我对电力系统的感受很明确：
电池容量本身很重要，但稳定性更重要。
原来的二手嘉百达 BMS 出现过断连和 MOS 自动关闭，既影响监控数据，也影响实际供电。后来更换为极空保护板，就是为了先把底层稳定性解决掉。
003 节点后续要做的，不是取代 BMS，而是作为整车控制系统的一部分，把电力状态汇总到数据面板里。
BMS 负责底层保护；
003 负责状态展示和联动入口；
000/HA 负责更高级的自动化判断。
这个边界必须清楚。
七、004 水路控制：从进水事故里长出来的节点
004 节点是最有教训意义的节点。
第一次露营时，水路高压漏水，直接导致 004 节点进水失联。好在后来用酒精清洗、晾干之后恢复了。
这件事让我意识到：水路控制节点不能只关心“能不能控制水泵”，还要考虑防水、防漏、检修和异常保护。
004 节点规划的功能包括：
净水剩余；
污水比例；
进水流量；
出水流量；
水泵档位；
UV 杀菌灯控制；
后续漏水检测和异常停泵。
![图7：004 水路控制界面]
水路节点有一个特殊点：
它既是低压电控，又靠近水。
所以它后续必须做防水盒和水电隔离。控制板不能裸露在水泵、水管、接头旁边，所有接线都应该通过防水接头进出，至少要做到“漏水时不直接浇到板子上”。
004 的后续重点不是增加花哨功能，而是提高可靠性：
水泵控制要稳定；
UV 杀菌灯要可控；
流量数据要能上报；
节点要防水；
漏水后要能保护，而不是继续工作到烧板。
八、005 移动终端：遥控器，不是核心节点
005 节点的定位比较特殊。
它不是固定安装在某个设备舱里的传感器节点，而更像一个移动终端，也可以理解成一个全息遥控器/便携控制端。
它的作用是：
发送指令；
触发场景；
作为临时遥控入口；
不承担核心状态上报。
![图8：005 移动终端状态界面]
这个定位很重要。
因为移动终端可能会没电、离线、拿到车外，不能让它承担影响整车安全的关键逻辑。它可以控制灯光、触发模式、发送指令，但不应该成为水泵保护、BMS 保护、逆变器控制的唯一入口。
简单说：
005 可以发号施令，但不能决定整车生死。
九、006 逆变器/充电节点：只旁路，不越权
006 是整套系统里最需要谨慎的节点。
这台车的逆变器是双向逆变器，既能从电池逆变到 220V，也能接入 220V 给电池充电，还涉及市电旁路、负载供电、充电状态等复杂逻辑。
一开始很容易产生一个想法：既然能抓到通信帧，那 ESP32 能不能直接伪造控制帧，控制逆变器开关和充电开关？
最终我们把原则定死：
006 节点只做旁路监听和模拟按键，不直接向逆变器发送协议控制帧。
也就是说，ESP32 不直接冒充逆变器原控制板，不向逆变器发送控制协议。
它只做两件事：
第一，旁路监听状态帧。
通过监听逆变器和原控制板之间的数据，判断市电输入、充电状态、逆变输出电压、电流、功率、频率等状态。
第二，模拟原机按键。
逆变器开/关通过模拟 B2_INVERTER 长按约 2000ms 实现；充电开/关通过模拟 B1_CHARGE 长按约 2000ms 实现。
![图9：006 逆变器节点旁路监听与模拟按键示意图]
这个设计的核心是安全边界。
控制逻辑依然走原机按键路径，ESP32 只是替代人去按按钮；
状态判断则通过旁路监听完成，用状态帧确认按钮效果。
之前抓到的短帧，比如逆变或充电相关帧，只作为理解按键动作的旁证，不直接拿来控制逆变器。
006 节点后续会承担几个很关键的判断：
市电是否接入；
充电是否开启；
逆变输出是否开启；
输出电压是否正常；
负载功率是否存在；
当前是电池供电还是市电旁路。
特别是之前提到的一个需求：在充电站插着 220V 过夜时，希望车内用电优先来自市电，电池保持满电，而不是电池充满后充电停止，车内直流设备继续消耗电池。
这个需求最终也要靠 006 的状态判断和控制策略配合实现。
但原则不变：
不越权，不伪造控制协议，只模拟按键，并用状态帧确认结果。
十、008 语音控制节点：好用，但必须能关闭
008 节点是给 SU-03T 离线语音模块准备的。
我不希望房车语音控制依赖云端，所以语音识别尽量走本地离线模块。SU-03T 识别到指令后，通过串口把指令发给 ESP32，再由 ESP32 转成 MQTT 指令，控制灯光、空调、逆变器、水泵等设备。
![图10：008 语音控制节点与 SU-03T 模块]
语音控制的优点很明显：
晚上躺在床上，不用摸手机；
手上拿东西时，不用找开关；
车内灯光、风扇、空调都可以一句话控制。
但语音控制也有一个很现实的问题：
误唤醒。
尤其是睡觉时，如果语音模块误识别，半夜突然开灯、开风扇、开逆变器，那体验会非常差。
所以 008 节点必须有总开关，而且数据面板里要增加：
语音平台启用开关；
自动化启用开关；
睡眠模式限制；
部分危险指令二次确认或禁用。
我的设计思路是：
白天可以开放更多语音指令；
晚上进入睡眠模式后，语音控制降级，只保留少数安全指令，或者直接关闭。
这样语音节点才是便利功能，而不是新的风险来源。
十一、通信方式：MQTT 是整车神经信号
整车各节点之间不直接互相硬连，而是通过 MQTT 通信。
每个节点主要做两类事情：
发布状态；
接收指令。
例如：
rv/002/light/state
rv/002/light/set
rv/003/power/state
rv/004/water/state
rv/006/inverter/state
rv/006/inverter/set
rv/008/voice/event
实际主题名称后续可以继续规范，但原则是统一的：
状态主题用于上报；
控制主题用于下发；
在线状态用于判断节点是否掉线；
关键设备状态要有反馈，不只发命令。
![图11：MQTT 主题规划示意图]
在控制系统里，一个非常重要的原则是：
命令发出不等于执行成功。
比如点击“打开逆变器”，只是说明 000 或手机面板发出了指令；
006 模拟按键后，还要通过状态帧判断逆变输出是否真的开启。
同样，点击“打开水泵”，004 也应该能反馈水泵状态，甚至后续通过流量计判断是否真的有水流。
这就是闭环控制和普通遥控的区别。
十二、自动化逻辑：先保守，再智能
现在很多东西都可以自动化，但我不打算一开始就让它“太聪明”。
房车是一个小空间，水、电、热、强电、低压电都在一起。自动化逻辑如果写得太激进，反而可能出问题。
目前比较适合先做的自动化包括：
1. 空调散热保护
冷凝器温度过高 → 开启辅助轴流风机
冷凝器温度继续升高 → 提醒/报警
温度恢复 → 延时关闭辅助风机
2. 水路保护
水泵开启但无流量 → 延时关闭水泵
漏水检测触发 → 关闭水泵 + 报警
UV 杀菌灯定时开启 → 到时自动关闭
3. 电力保护
SOC 过低 → 关闭非必要负载
电池温度异常 → 提醒
大功率负载开启时 → 面板提示当前功率
4. 睡眠模式
睡眠模式开启 →
降低灯光亮度
关闭 RGB 特效
限制语音控制
降低误触发风险
5. 市电接入模式
检测到市电输入 →
优先市电供电
允许充电
尽量保持电池满电
这些逻辑都会逐步加，不会一次全部写死。
我的原则是：
能手动稳定使用，再加自动化；自动化必须可关闭；危险动作必须有反馈。
十三、强弱电边界：控制不是乱接线
这套控制系统里，ESP32 只负责低压控制和信号采集，不能直接碰 220V 强电大电流。
强电部分必须通过：
继电器；
接触器；
MOS 模块；
保险；
漏保；
断路器；
合适线径；
端子排；
线槽和波纹管。
![图12：强电、弱电、信号线分区走线]
之前水路进水导致 004 节点失联，也提醒我：低压电控虽然电压不高，但照样需要防水、防短路、防震动。
房车不是固定房屋，它会行驶、震动、温度变化、湿度变化。所有线束都不能只靠临时缠胶带，后续必须逐步整理：
强弱电分开走；
水路和电控隔离；
关键线路加保险；
接头做标签；
控制板进盒；
线束固定，避免磨损。
这部分不如写代码有意思，但它决定了系统能不能长期稳定使用。
十四、当前完成度
目前整车控制架构已经不是单纯停留在想法阶段，部分节点和面板已经开始运行。
已经具备雏形的部分
000 本地数据面板；
002 睡眠舱灯光控制；
003 电力系统状态展示；
004 水路控制界面；
005 移动终端入口；
部分 MQTT 通信逻辑；
语音节点 008 的功能规划；
逆变器节点 006 的旁路监听与模拟按键原则。
正在继续完善的部分
006 逆变器/充电状态解析；
空调冷凝器 NTC 温度监测；
水路节点防水外壳；
MQTT 主题规范；
000 面板布局优化；
语音平台启用开关；
自动化启用开关；
睡眠模式逻辑。
后续计划
把各节点代码统一规范；
给每个节点增加详细串口调试日志；
给关键节点增加离线状态提示；
完善 Home Assistant 接入；
整理线束和控制盒；
增加图形化系统架构图；
建立露营模式、行车模式、睡眠模式、市电模式。
![图13：当前数据面板与节点在线状态截图]
十五、这一阶段的总结
Vol.1 到 Vol.5，更多是在解决“车能不能住”的问题。
到了 Vol.6，开始进入另一个阶段：
让这台车能被理解、能被监控、能被控制。
之前的改装更像是在搭建身体：
地板是骨架，床是空间，电池是心脏，水路是循环系统，空调是体温调节。
而现在的 ESP32 节点、MQTT、000 面板、Home Assistant、语音模块，就是这台车的神经系统。
它们不一定让车立刻看起来更漂亮，但会让车变得更可靠、更可控，也更接近我一开始设想的“移动智能小家”。
这套系统的目标不是炫技，而是解决真实问题：
我想知道电池还剩多少；
我想知道水箱还剩多少；
我想知道空调为什么停机；
我想知道水泵有没有异常；
我想在床上关灯；
我想在睡觉时关闭语音误触发；
我想插上市电后让电池保持满电；
我想在出现问题前先看到预警。
这就是 Vol.6 的意义。
从这一篇开始，这台车不再只是一个装满设备的货车车厢，而开始变成一套可以感知、判断和响应的系统。
下一步，就是把这些节点逐个落地，把控制逻辑从“能跑”变成“稳定、可维护、可扩展”。
