1. 这个冰箱贴到底解决了什么问题

家里冰箱门上贴一张购物清单，这件事听起来简单到不值一提，但真正过日子的人都知道，它其实是个高频刚需。纸质便签写完就扔、白板笔擦来擦去一手墨、手机备忘录记了但进厨房又懒得掏手机——这些场景我都经历过。PaperMono 这个项目的切入点就在这里：用一块电子墨水屏做成冰箱磁贴，显示购物清单，手机浏览器打开网页就能同步修改，固件跑在设备端负责刷新和联网。

核心关键词是PaperMono、电子墨水、固件、手机网页同步。说白了，它是一套软硬件结合的小系统：硬件是一块带电池的电子墨水屏加磁贴背板，固件负责驱动屏幕、连接网络、拉取清单数据，手机端不需要装 App，打开一个网页就能编辑清单，改完自动推到冰箱贴上。适合谁来参考？如果你玩过 ESP32、树莓派 Pico 这类开发板，想做一个真正每天都会用的小物件，这个项目非常合适；如果你只是想找个现成的购物清单工具，那它也能给你一套自建方案的完整思路。

我之所以对这个项目感兴趣，是因为它踩中了几个很实际的设计取舍：为什么用电子墨水而不是 LCD？为什么固件要自己做而不是买个成品？为什么手机端用网页而不是 App？这些选择背后都有明确的理由，后面我会逐个拆开讲。

2. 整体设计思路与方案选型拆解

2.1 为什么是电子墨水屏而不是普通屏幕

电子墨水屏最大的特点是双稳态——断电之后画面还在，不刷新就不耗电。冰箱贴这个东西，一天可能只看两三次，改清单也就几分钟一次，如果用 LCD，屏幕得一直亮着或者频繁唤醒，电池撑不了几天。电子墨水屏在静态显示时功耗几乎为零，只有刷新那一瞬间才吃电，这直接决定了整机可以用小电池跑几个月。

另一个原因是可视角度和观感。冰箱贴是贴在金属门上的，人站着、弯腰、侧着看都有可能，电子墨水屏的可视角度接近纸张，不像 LCD 那样偏一点就发白。而且它不发光，厨房灯光下看着不刺眼，这点在真实使用里比参数表上写的更重要。

当然代价也有：刷新慢，通常全刷要一两秒，局刷快一些但会有残影。所以固件设计上必须考虑刷新策略——不是每次改一个字就全屏刷，而是攒一批改动再刷，或者用局刷加定期全刷清残影。这个取舍我在第 4 部分会详细讲。

2.2 固件为什么要自己写

市面上有现成的电子价签、电子备忘录，但它们的固件是封闭的，你没法改刷新逻辑、没法接自己的同步服务、没法控制功耗策略。PaperMono 选择自己写固件，核心目的是把控制权拿回来。

固件要干的事其实就几件：驱动墨水屏、连 Wi-Fi、跟服务端同步清单、管理电池和休眠。听起来不多，但每一件都有坑。比如墨水屏驱动，不同型号的波形表不一样，直接抄别人的代码可能显示发灰或者残影严重；比如 Wi-Fi 连接，如果每次唤醒都重新握手，功耗会飙升，得做连接复用或者快速重连。

自己写固件的另一个好处是可以针对场景做极致优化。购物清单这个场景，数据量极小（几十个字符），更新频率极低（一天几次），完全可以把固件做成“深度休眠 + 定时唤醒 + 事件唤醒”的模式，把平均功耗压到微安级。

2.3 手机网页同步而不是 App

这是我觉得最聪明的一个选择。做一个 App 要处理 iOS 和 Android 两套、要上架、要更新，成本高且没必要。购物清单就是个文本列表，用网页做编辑器，手机浏览器打开就能用，改完点保存，服务端存下来，设备下次唤醒时拉取。

网页同步的技术栈可以很轻：一个简单的后端接口（比如 REST 或者 WebSocket），前端就是一个带输入框和列表的页面。设备端固件用 HTTP 轮询或者长连接接收更新通知。这里的关键是冲突处理——如果两个人同时改清单怎么办？常见做法是服务端以最后一次写入为准，或者给每条记录加时间戳做合并。对于家庭购物清单这种场景，最后写入为准基本够用，但固件端要处理好“本地未提交的改动”和“远端新改动”的关系，避免把刚输入的内容覆盖掉。

3. 核心细节解析与实操要点

3.1 硬件选型与接线要点

电子墨水屏模块常见的有微雪（Waveshare）系列、Good Display 系列，尺寸从 1.54 寸到 7.5 寸都有。冰箱贴这个场景，我建议选2.9 寸到 4.2 寸之间，太小显示不了几行，太大贴冰箱上显得笨重。分辨率方面，2.9 寸通常是 296x128，4.2 寸是 400x300，显示十几行购物清单完全够用。

主控方面，ESP32 是最稳妥的选择，自带 Wi-Fi、功耗管理成熟、社区资料多。如果追求更低功耗，可以用 ESP32-C3 或者带 ULP 协处理器的型号。电池用 3.7V 锂聚合物电池，容量 1000mAh 到 2000mAh 就够跑很久，具体算一下：假设深度休眠电流 20uA，每天唤醒 10 次、每次工作 5 秒、工作电流 80mA，那么日均耗电大约是 20uA×24h + 80mA×50s/3600 ≈ 0.48mAh + 1.11mAh ≈ 1.6mAh，2000mAh 电池理论上能跑三年以上，实际考虑自放电和刷新功耗，半年到一年充一次电是合理预期。

接线方面，墨水屏模块一般用 SPI 接口，需要接 CS、DC、RST、BUSY、CLK、DIN 这几根线，具体引脚定义看模块手册。注意BUSY 引脚一定要接，固件靠它判断屏幕是否忙，不接的话刷新会出错。另外建议加一个物理按键用于手动刷新或配网，不然设备休眠后你没法主动触发操作。

3.2 固件架构与关键模块

固件我建议分成几个清晰的模块，别全塞在一个文件里：

• 显示驱动层：封装墨水屏的初始化、全刷、局刷、休眠。不同屏幕型号的波形表要单独适配。
• 网络层：Wi-Fi 连接管理、HTTP 客户端、可能的 WebSocket 客户端。要处理断线重连和超时。
• 同步逻辑层：拉取清单、对比本地版本、决定是否刷新、提交本地改动。
• 电源管理层：休眠唤醒、外设供电控制、电池电压监测。
• 配网与配置：首次使用时怎么让设备连上你家 Wi-Fi，常见做法是设备开一个热点，手机连上去填 Wi-Fi 信息，或者用 SmartConfig 这类一键配网。

这里重点说同步逻辑。一个可靠的流程是：设备唤醒后先连 Wi-Fi，向服务端请求清单的版本号或哈希值，如果跟本地一致就跳过刷新直接睡；如果不一致就拉取完整清单，渲染到屏幕，更新本地版本号，然后睡。本地改动（如果设备支持输入）则反过来，先提交到服务端，成功后再刷新屏幕。

注意：墨水屏刷新期间绝对不能断电，否则可能损坏屏幕或者留下永久残影。固件里要在刷新前确保电池电压足够，低于阈值就拒绝刷新并提示充电。

3.3 手机网页端的设计要点

网页端不需要花哨，核心功能就三个：显示当前清单、添加/删除条目、保存同步。但有几个细节直接影响体验：

第一，输入框要支持回车快速添加，买菜的场景是一边看冰箱一边记，操作越少越好。第二，已购条目要能一键清除或者折叠，不然清单越用越长。第三，页面要适配手机竖屏，字体别太小，按钮别太密。

技术上，前端可以用原生 HTML+JS，也可以用轻量框架。后端如果只是家庭自用，一个简单的服务加上 SQLite 或者 JSON 文件存储就够了。接口设计上，GET /list返回清单，POST /list提交更新，GET /version返回版本号供设备轮询。如果想做得更实时，可以用 WebSocket 让设备保持长连接，但那样功耗会高一些，需要权衡。

3.4 刷新策略与残影处理

电子墨水屏的残影是个绕不开的问题。局刷速度快但会累积残影，全刷干净但闪屏明显、速度慢。我的经验是采用混合策略：日常小改动用局刷，每刷 5 到 10 次局刷后做一次全刷清残影，或者每天固定时间做一次全刷。

具体实现上，固件里维护一个局刷计数器，每次局刷后加一，达到阈值就触发全刷并清零。全刷的时机可以选在深夜或者设备长时间休眠后第一次唤醒时，这样闪屏对用户影响最小。

另外，刷新前要先清屏再写新内容，直接覆盖写容易留鬼影。有些驱动库提供了clear()和display()两个步骤，别偷懒只调一个。

4. 实操过程与核心环节实现

4.1 开发环境搭建

以 ESP32 为例，我习惯用 ESP-IDF 或者 PlatformIO。PlatformIO 对新手更友好，库管理方便。装好之后新建项目，选对开发板型号，然后把墨水屏驱动库加进依赖。

# PlatformIO 项目初始化示例 pio project init --board esp32dev # 在 platformio.ini 中添加依赖 # lib_deps = # waveshare/gxepd2 # bblanchon/ArduinoJson

如果你用 Arduino 框架，那就装 ESP32 板支持包，再装 GxEPD2 或者类似驱动库。注意不同库对屏幕型号的支持不一样，买屏幕时看清楚驱动芯片型号（比如 SSD1680、UC8176 等），选对应的库。

4.2 屏幕驱动跑通

第一步永远是让屏幕能显示东西。写一个最小程序，初始化屏幕，显示一行文字，确认接线和驱动没问题。

// 伪代码示意，具体API看所用库 display.init(); display.setRotation(1); display.setFont(&FreeMonoBold9pt7b); display.setTextColor(GxEPD_BLACK); display.setFullWindow(); display.firstPage(); do { display.fillScreen(GxEPD_WHITE); display.setCursor(10, 30); display.print("Shopping List"); } while (display.nextPage());

这一步常见的坑是接线错误导致 BUSY 一直忙，或者波形表不匹配导致显示发灰。如果屏幕全白或者全黑，先查接线，再查驱动型号。如果显示内容但对比度差，多半是波形表问题，换库或者手动调 LUT。

4.3 Wi-Fi 连接与配网

配网我推荐用ESP32 的 WiFiManager 库，它会在连不上已知 Wi-Fi 时自动开热点，手机连上去弹出配置页面，填完保存重启。这样你不需要在代码里硬编码 Wi-Fi 密码，也方便换环境。

// WiFiManager 配网示意 WiFiManager wm; bool res = wm.autoConnect("PaperMono-AP"); if (!res) { // 配网失败，进入休眠或重试 }

连上之后，固件要能处理断线重连。我的做法是设置一个连接超时，比如 10 秒连不上就放弃本次同步直接睡，下次唤醒再试。不要无限重试，那样电池很快耗光。

4.4 清单同步的完整流程

设备端的同步流程我整理成下面这张表，方便对照实现：

服务端这边，版本号可以用清单内容的哈希或者一个自增整数。每次网页端保存时版本号加一，设备拉取时带上本地版本号，服务端返回 304 或者新数据。这样能最大程度减少数据传输和刷新次数。

4.5 电源管理与休眠调优

ESP32 的深度休眠电流可以做到 10uA 左右，但前提是关掉所有不必要的外设电源。墨水屏模块在休眠时也要断电，否则它自己会耗电。具体做法是用一个 MOS 管控制屏幕的 VCC，休眠时拉低。

唤醒源可以配多个：定时器唤醒（比如每 30 分钟检查一次更新）、按键唤醒（手动刷新）、外部中断唤醒（如果有传感器）。购物清单场景，定时 30 分钟到 1 小时检查一次足够了，太频繁没必要。

实操心得：调试功耗时，先用万用表测休眠电流，如果超过 100uA，检查是不是有 LED 没关、稳压器静态电流太大、或者某个引脚悬空导致漏电。我踩过的一个坑是串口芯片没断电，白白多耗了几百微安。

5. 常见问题与排查技巧实录

5.1 屏幕显示异常排查

5.2 同步失败排查

同步失败最常见的原因是Wi-Fi 连不上和服务端地址写错。我的排查顺序是：先用串口打印 Wi-Fi 连接状态，确认能拿到 IP；再用浏览器或者 curl 测试服务端接口是否可达；最后检查固件里的 URL 和端口。

另一个坑是HTTPS 证书。如果服务端用了自签名证书，ESP32 默认会拒绝连接。解决办法是要么用 HTTP（内网自用可以接受），要么把证书指纹写进固件做校验。

5.3 电池续航不达预期

如果发现电池掉得比预期快，按这个顺序查：先测休眠电流，再测工作电流和单次工作时长，最后算日均耗电。常见问题包括：Wi-Fi 没真正断开、屏幕没断电、定时唤醒间隔太短、某个传感器一直在采样。

我遇到过一次续航只有几天的情况，最后发现是固件里有个delay()在循环里，导致设备根本没进休眠。所以休眠前一定要确认所有任务都挂起或者删除，别留后台任务偷偷跑。

5.4 网页端同步冲突

两个人同时改清单时，可能出现一方改动被覆盖。简单做法是服务端记录最后修改时间，设备拉取时如果发现远端版本比本地新就覆盖本地。如果要做更细的合并，可以给每个条目加唯一 ID 和删除标记，合并时按 ID 对齐。家庭场景下，最后写入为准基本不会出问题，但如果经常多人同时编辑，建议加一个“正在编辑”的提示或者乐观锁。

6. 一些实际使用后的体会

这个项目我从打样到日常使用大概折腾了一个多月，最大的感受是电子墨水屏的刷新体验决定了整个产品的成败。刚开始我每次改动都全刷，闪得人眼晕，后来改成局刷为主、全刷为辅，体验立刻上了一个台阶。另一个体会是配网一定要做简单，我第一版硬编码 Wi-Fi 密码，换路由器后设备直接变砖，后来换成 WiFiManager 才省心。

还有一点，别低估手机网页的便利性。我一开始想做个 App，后来发现网页完全够用，而且改起来快、不用审核、家人也能直接用。如果你也在做类似的东西，我建议先把最小可用版本跑通：屏幕能显示、网页能改、设备能同步，这三件事通了，剩下的都是优化。

后续如果想扩展，可以加语音输入（手机网页调麦克风）、加到期提醒（清单条目带日期）、加多设备同步（厨房一个、玄关一个）。但核心逻辑不变，还是那套“网页编辑、服务端存储、设备拉取刷新”的架构。