一、WaterMonitor 量产开发优先级
我把接下来的工作分成 6 个阶段、18 项任务。
| 优先级 | 工作项目 | 重要程度 | 当前情况 |
|---|---|---|---|
| P0-01 | 修复配置保存失败 | ⭐⭐⭐⭐⭐ | ? 已发现问题 |
| P0-02 | 验证配置断电保存 | ⭐⭐⭐⭐⭐ | 待测试 |
| P0-03 | 固定黑白屏局部刷新程序 | ⭐⭐⭐⭐⭐ | 已基本完成 |
| P0-04 | 固定三色屏稳定版本 | ⭐⭐⭐⭐⭐ | 已基本完成 |
| P1-01 | 完善 /entities 配置页面 | ⭐⭐⭐⭐ | 开发中 |
| P1-02 | 完善主标题自定义 | ⭐⭐⭐⭐ | 待开发 |
| P1-03 | 完善时间显示设置 | ⭐⭐⭐⭐ | 待开发 |
| P1-04 | 统一黑白、三色屏功能 | ⭐⭐⭐⭐ | 待验证 |
| P2-01 | 加入固件版本号 | ⭐⭐⭐⭐⭐ | 待开发 |
| P2-02 | 加入设备唯一编号 | ⭐⭐⭐⭐ | 待开发 |
| P2-03 | 增加 OTA 固件升级 | ⭐⭐⭐⭐⭐ | 待开发 |
| P2-04 | 完善异常恢复机制 | ⭐⭐⭐⭐⭐ | 待开发 |
| P3-01 | 选定量产 ESP32 型号 | ⭐⭐⭐⭐⭐ | 待确定 |
| P3-02 | 设计量产 PCB | ⭐⭐⭐⭐⭐ | 待开发 |
| P3-03 | 制作批量烧录方案 | ⭐⭐⭐⭐⭐ | 待开发 |
| P4-01 | 评估固件加密保护 | ⭐⭐⭐⭐ | 待开发 |
| P4-02 | 完成整机可靠性测试 | ⭐⭐⭐⭐⭐ | 待测试 |
| P5-01 | 小批量试产与验收 | ⭐⭐⭐⭐⭐ | 待开展 |
这里的 P0、P1、P2 表示任务优先级，P0 最高。
二、第一阶段：先解决程序稳定性（P0）
这是我们现在最应该做的工作。
① 修复配置保存失败
你之前的 /entities 页面出现过：
保存失败：配置存储失败，原配置保留
这个问题必须排在第一位。
因为现在我们的网页已经支持越来越多的配置：
HA 实体绑定。
自定义实体名称。
MDI 图标。
黑白及灰色图标设置。
时间显示设置。
后续增加的主标题设置。
如果配置无法可靠保存，后面的功能越多，问题可能越严重。
验收标准：
连续保存配置 100 次，全部成功；断电重启后配置不丢失。
同时需要测试存储空间不足、配置格式错误等异常情况。
② 验证黑白屏局部刷新
我们之前已经成功实现了：
数字局部刷新。
50% 中灰显示。
右上角时间局部刷新。
累计局刷后整屏刷新。
现在不需要重新开发这些功能。
只需要把已经验证成功的版本保存下来，避免后续修改破坏它们。
建议保存：
WaterMonitor_BW_Stable_V1.0
三色屏也单独保存稳定版本。
第一阶段完成后，我们才继续增加功能。
三、第二阶段：完善用户配置功能（P1）
这一阶段主要让墨水屏成为真正可以交付给普通用户的产品。
③ 完善 /entities 页面
保留我们之前确定的功能：
自定义实体名称。
自定义 MDI 图标。
sensor./switch.实体选择。黑色、50% 中灰图标设置。
保存后自动更新屏幕。
同时增加配置数据校验，防止错误数据导致程序异常。
④ 增加主标题设置
我们刚刚讨论过，墨水屏已经不再局限于水质监测。
因此建议：
默认标题由「水质监测」改为 「智能看板」。
用户可以自行修改为：
环境监测
智能家居
鱼缸监控
设备状态
并支持恢复默认设置。
⑤ 完善时间显示设置
按照之前确定的方案：
默认显示
HH:MM。每秒检查一次系统时间。
分钟变化时局部刷新。
网页可以调整字体大小。
网页可以调整 X/Y 坐标。
可以开启或关闭时间显示。
这一阶段的目标：用户不需要修改 Arduino 代码，就能完成日常配置。
四、第三阶段：增加量产固件管理（P2）
这是产品化过程中最重要的升级。
⑥ 增加固件版本号
建议采用统一版本规则：
WaterMonitor V1.0.0
在网页中显示：
| 项目 | 示例 |
|---|---|
| 产品名称 | 智能墨水屏看板 |
| 固件版本 | V1.0.0 |
| 硬件版本 | HW1.0 |
| 设备编号 | WM-000001 |
| Wi-Fi IP | 192.168.31.100 |
| 屏幕类型 | 4.2 英寸黑白 |
这些信息可以帮助我们以后定位售后问题。
⑦ 增加设备唯一编号
建议使用 ESP32 芯片的唯一 MAC 地址作为生成编号的依据。
不建议直接使用 WM-000001 这样的流水号，除非我们建立了统一的生产编号管理系统。
设备编号应当能够在网页中查看。
⑧ 增加 OTA 无线升级
建议第一版先实现：
用户通过网页上传 .bin 文件升级固件。
暂时不开发云端自动升级服务器。
这样成本低、开发难度适中，而且足够满足第一批产品使用。
但 OTA 必须具备基本的安全措施：
需要管理员身份才能上传。
校验固件是否适用于当前硬件。
防止升级中断造成设备无法启动。
升级后尽量保留用户配置。
特别提醒：我们当前的固件约 2.22MB，如果使用双 OTA 分区，建议优先选择 8MB Flash。
⑨ 完善异常恢复
重点处理：
Wi-Fi 断线、HA 无响应、网络超时、配置异常以及意外重启。
确保设备在没有 Home Assistant 连接的情况下，也不会一直卡死。
五、第四阶段：确定量产硬件（P3）
等软件功能基本固定以后，再决定最终 PCB。
⑩ 选择 ESP32
我建议优先考虑：
ESP32-C3-MINI-1-H8X（8MB Flash）
主要原因：
与当前 ESP32-C3 软件架构接近。
模组体积较小。
8MB Flash 便于规划 OTA 分区。
已经集成 Wi-Fi 射频电路和天线。
不过，最终采购前必须确认供货渠道、价格、引脚和封装规格。
⑪ 设计简化 PCB
墨水屏只需要 6 个 GPIO。
建议主板包括：
ESP32-C3 模组。
3.3V 电源电路。
墨水屏接口。
BOOT、RESET。
自动烧录测试点。
必要的滤波及去耦电容。
如果采用 5V USB 输入，需要设计 5V 转 3.3V 电路。
注意：墨水屏实际供电电压要以驱动板规格为准。
⑫ 制作量产烧录工装
建议沿用我们之前研究过的 CH340K 自动下载方案。
PCB 预留测试点，使用弹簧探针连接烧录器。
这样可以避免每块 PCB 都安装 USB 接口。
六、第五阶段：固件保护和可靠性验证（P4）
⑬ 固件保护
等 OTA、烧录和恢复机制全部验证完成，再评估：
Secure Boot + Flash Encryption
不要在开发阶段直接启用。
因为相关安全配置可能涉及不可逆的 eFuse 操作，必须先验证密钥管理、量产烧录和售后恢复流程。
⑭ 长期运行测试
建议至少完成：
| 测试 | 建议目标 |
|---|---|
| 连续运行 | 30 天 |
| Wi-Fi 断线恢复 | 自动重连 |
| HA 服务断开 | 不死机 |
| 意外断电 | 恢复后正常启动 |
| 局部刷新 | 长期无明显异常 |
| 配置保存 | 连续 100 次成功 |
| OTA 升级 | 多次升级及异常中断测试 |
| 内存稳定性 | 无持续性内存下降 |
这些测试可以与硬件样板制作并行进行，不必全部等到最后。
七、第六阶段：小批量试产（P5）
我不建议第一批直接生产 100 块。
更合理的安排是：
先制作 5～10 块 PCB。
逐块测试：
能否正常烧录。
能否正常启动。
Wi-Fi 配网是否成功。
墨水屏全刷、局刷是否正常。
HA 实体绑定是否正常。
配置能否保存。
OTA 升级是否正常。
通过以后，再考虑 50～100 块的批量生产。
八、我们现在具体应该从哪里开始？
我建议接下来按照下面这个顺序执行：
| 顺序 | 任务 | 预计工作量 |
|---|---|---|
| 第 1 项 | 修复 /entities 配置保存失败 | 优先立即处理 |
| 第 2 项 | 完善主标题和时间设置 | 小范围功能修改 |
| 第 3 项 | 固定黑白、三色稳定固件 | 版本整理 |
| 第 4 项 | 加入设备编号、固件版本 | 小范围功能修改 |
| 第 5 项 | 确定 8MB Flash 分区方案 | 硬件选型前完成 |
| 第 6 项 | 实现网页 OTA 升级 | 需要专项测试 |
| 第 7 项 | 完善异常恢复和固件安全 | 需要专项测试 |
| 第 8 项 | 确定 ESP32 型号并设计 PCB | 硬件开发 |
| 第 9 项 | 制作批量烧录工装 | 量产准备 |
| 第 10 项 | 小批量试产、可靠性测试 | 最终验收 |
其中，配置存储修复和稳定版本备份必须最先完成；OTA 分区方案也应在硬件定型前确认。
? 我们现在先做第 1 项
彻底解决 /entities 页面「配置存储失败，原配置保留」的问题。
这个问题直接关系到用户能否正常使用产品，也是后续增加主标题、时间设置、设备编号等功能的基础。
建议先不修改界面，也不增加新功能。
只针对现有程序检查：
配置数据结构 → NVS 存储空间 → 保存逻辑 → 错误返回 → 断电恢复。
等这一项通过测试，我们再进入下一项。
这样推进，既能保护我们已经开发成功的墨水屏功能，也能让整个项目逐步达到量产标准。
