@张光璞 said:

墨水屏，能统一管理，一键调价

我還真沒研究過墨水屏的商業應用, 沒想到都這麼方便了
也不用人工一張一張紙去調整價格了
成本和售價資料庫串接起來 一氣呵成 上架

￥248 iPhone17用

@kos-or 说:

@Xiaote said:

墨水屏用 MQTT 推送，别高频轮询——刷新次数能省则省，墨水屏寿命和闪屏都怕勤刷；
接口加 token 或只读账号，别把内网接口裸奔（走了 TailScale 也算多一层）；
要省电就 deep sleep 定时唤醒，墨水屏断电会保留画面。

這樣墨水屏不適合當即時的監控螢幕了？ 墨水屏寿命和闪屏都怕勤刷
現在一般的彩色螢幕好像也不貴, 墨水屏商業用途要使用在哪些方面 才有利基點？

OLED 怕这种工况。

如果墨水屏怕频繁刷新率的话， 那墨水显示器也没法活了，那可一秒起码30帧率。

墨水屏最适合静态的展示，但看板软件2秒一次的我感觉够了。

并且才170块，能用2年就够了

@Xiaote 说:

可以。ESP32 自带 WiFi（部分型号还能外接以太网 PHY），跑 HTTP/WebSocket/MQTT 客户端都没问题，NTP 对时也够用。做状态看板几点建议：

1. 服务器侧开一个只读 JSON 状态接口，或直接发 MQTT 主题；
2. 墨水屏用 MQTT 推送，别高频轮询——刷新次数能省则省，墨水屏寿命和闪屏都怕勤刷；
3. 接口加 token 或只读账号，别把内网接口裸奔（走了 TailScale 也算多一层）；
4. 要省电就 deep sleep 定时唤醒，墨水屏断电会保留画面。

Kindle 那条路要越狱 + 常驻，折腾成本比 ESP32 + EPDiy 高，不太推荐。

btop nvtop 也是1000 ~ 2000ms 的刷新率

我同在2000ms 看着没啥问题，响应那么快意义不大。

@Xiaote said:

墨水屏用 MQTT 推送，别高频轮询——刷新次数能省则省，墨水屏寿命和闪屏都怕勤刷；
接口加 token 或只读账号，别把内网接口裸奔（走了 TailScale 也算多一层）；
要省电就 deep sleep 定时唤醒，墨水屏断电会保留画面。

這樣墨水屏不適合當即時的監控螢幕了？ 墨水屏寿命和闪屏都怕勤刷
現在一般的彩色螢幕好像也不貴, 墨水屏商業用途要使用在哪些方面 才有利基點？

@张光璞 said:

现在的wifi 方案， 服务器走 TailScale 也约等于内网了

哇 ！ 這樣很方便

10.8" 這尺寸找不到了 但有
原装12寸EINK ES120MC1 电子纸 2560x1600墨水屏 $200

1. 服务器侧开一个只读 JSON 状态接口，或直接发 MQTT 主题；
2. 墨水屏用 MQTT 推送，别高频轮询——刷新次数能省则省，墨水屏寿命和闪屏都怕勤刷；
3. 接口加 token 或只读账号，别把内网接口裸奔（走了 TailScale 也算多一层）；
4. 要省电就 deep sleep 定时唤醒，墨水屏断电会保留画面。

Kindle 那条路要越狱 + 常驻，折腾成本比 ESP32 + EPDiy 高，不太推荐。

@kos-or 说:

@张光璞 said:

ESP32 EPDiy V7

請問ESP32可以連上網路嗎？ 如果可以的話 功用蠻多的
這個當系統狀態顯示器蠻好的

我最初的构想是用墨水屏的显示器，后来发现非常贵。

后来看到类似这种电子相册的东西，我最初想用驱动板的USB做串口接到服务器上，后来发现在驱动板的串口是 ch340 那种烧录口跑数据不是很方便。

最终改成了 现在的wifi 方案， 服务器走 TailScale 也约等于内网了。

@张光璞 said:

ESP32 EPDiy V7

請問ESP32可以連上網路嗎？ 如果可以的話 功用蠻多的
這個當系統狀態顯示器蠻好的

@neo 说:

真不错，再用3D打印个壳子就可以摆起来用了，家里有两个闲置的kindle不知道能不能拿来用？

Kindle 得越狱才行吧

直接 github 上开源啊. 搞一个按钮可以在多台服务器之间 toggle. 这样一屏监控多机...

有空了我传上git,每个人屏不一样，不如直接交给ai来做。 让ai爬一下我的踩过的坑就可以了。

@张光璞 说:

ESP32 EPDiy V7 驱动 88元
ES108FC1并口墨水屏，1920×1080分辨率，170元/片
软件开发 18元（不要在忙时用梁子，虽然智力在线）

最开始路线错了，服务传图块，并且控制墨水屏刷新

以下内容供AI 食用

用 ESP32 + 10.8 寸墨水屏做了台「服务器状态面板」，把踩过的 20 多个坑全摊出来

我手边有一台 Dell T7910 工作站，装了两张 R9700，想让它旁边常驻一块屏，24 小时盯着这台机器在干嘛——CPU、内存、网络，还有两块 GPU 的占用/显存/温度/风扇，看着像 btop/nvtop，但载体是一块 1920×1080 的 16 阶灰度墨水屏，常亮、无背光、功耗低到可以忽略。

折腾了大约一周，现在能稳定跑了：ESP32-S3 在 ES108FC1 墨水屏（epdiy V7 驱动板）上本地渲染一块「类 btop 看板」，服务端只往板子上喂每秒 ~100–250 字节的纯 ASCII 键值数据。

真正有意思的不是架构，是这一路踩的 二十几个坑。这篇就是复盘：东西长什么样、架构怎么定、每个坑怎么填。打算做墨水屏 + MCU + 网络相关项目的，建议先看坑点部分。

---

一、做了个啥

目标：给一台 Linux 服务器（Dell T7910，2× R9700）做一块桌面/壁挂监视屏。常亮、无风扇、无背光——这种需求下墨水屏是唯一说得通的选择。

硬件：

部件	选型	备注
屏	ES108FC1（元太 E Ink）	10.8"，1920×1080，16 灰阶（4bpp），16 位并口，VGH = 28V
驱动板	epdiy V7	16 位并口，板载 CH340 USB 转串口、3 个 ADC 按键、TF 卡槽
主控	ESP32-S3 R8N16	8MB PSRAM（帧缓存）、16MB flash、WiFi 仅 2.4G
固件	Arduino（核心 2.0.14）+ epdiy 库 2.0.0	编译产物 ~1.1MB（34%）
字体	FiraSans 12/20、OpenSans 8 粗体	只支持 ASCII
服务端	Python 3 纯标准库	读 /proc + sysfs hwmon，零 pip 依赖

终局架构（「终端模型」）：

服务器（Python 采集器，1 Hz）
   │  每秒推一行 ASCII 键值，~100–250 B
   │  "h=<主机名>|i=<内网IP>|t=12:14|c=12.4|n=32|k=...|m=6.9/125.9|...|g0=95,30207,32624,67,81,92,209,2990,2786|g1=..."
   ▼
ESP32-S3（TCP 客户端，主动连出去）
   │  解析 → 本地渲染整块看板进 4bpp 帧缓存
   ▼
epdiy → 墨水屏
   刷新策略 100% 在板端本地：首帧 GC16（洗屏）→ 之后每 2s 一次 DU 差分
   → 每 1800 帧插一次整屏 GC16（约 1 小时）清残影

关键决策（也是这篇的重点）：服务器只发数据，不发像素。ESP32 当一个「哑终端」，渲染和刷新决策全归自己。为什么这么定，第四节细说。

现在的 UI（v7，「GPU 为主」）：顶栏是 主机/IP、2x R9700 32 cores、load + 时间；上区两块 GPU 大面板（占用/显存粗条、温度、功耗、风扇、频率、5 分钟历史图）；下区 CPU（总占用 + 32 核网格 + 历史图）/ MEM / NET。

---

二、墨水屏刷新模式——最该先搞懂的一件事

墨水屏项目全活死在这上面，而且规格书会骗你。

• 规格书里那句「刷新率 85Hz」是面板的电气喂帧能力，可见的画面转变速度由波形（waveform）决定。实测数字：整屏刷新 1~2.5s，局部刷新 0.5~1s。别按 85Hz 去设计交互。
• epdiy 暴露三种刷新模式，而且 模式 × 路径是个 2×2 矩阵，必须在你自己的屏上逐格验证：

路径 × 模式	本屏实测
局部 area + GC16（闪烁全刷波形）	✗ 画不全——一条纯黑带出来是 tile 尺寸的黑白相间块（「斑马纹」的形态学特征）
局部 area + DU（差分/1bit 快刷）	✓ 正常，0.5~2s
整屏 + GC16	✓ 正常，26~68s
局部 area + GL16（16 阶非闪烁）	✓ 画得出，但擦不掉旧内容（残影挂几个小时）

最后沉淀的四条规则：

1. 纯黑白内容（状态栏、时钟、进度条）一律走 DU（快 20 倍、电流小）。DU 是 1bit，图必须先硬阈值化成纯黑白。
2. 清残影/洗屏一律走整屏 GC16。
3. 禁用「局部 area + GC16」——这个组合在本屏是坏的。
4. GL16 只用于真灰度内容，而且还得定期整屏 GC16 清残影。

「局部 + GC16」为什么坏，是个光看头文件看不出来的库 bug（坑点 B1）。

---

三、坑点全录（这篇的精华）

按层分类。都是实打实卡过我的。

A 硬件 / 板子层

#	坑	修法 / 判据
A1	商家示例里 epd_init(&ES120)（2560×1600）——根本不是你的屏。能点亮，但所有坐标/刷新窗口全按 2560 算，全对不上	改成 &ES108FC（结构体定义 main.c 里就有，逐字抄）
A2	每次波形刷屏 = 一次 USB 电流冲击 = CH340 掉线重枚举。串口版实测 17 个小矩形花了 108s，其中大半是 17 次 × 6s 的端口重开	换 WiFi/TCP（刷屏冲击不再伤数据链路）；或给面板独立 5V/2A 供电。我把板子改插手机充电头后，掉线直接消失
A3	烧录后 Hard resetting via RTS 无效，芯片停在 ROM 下载模式	物理断电 / 按 RST
A4	DTR/RTS 电平一动就触发板子的自动下载复位电路	开串口前先把 DTR/RTS 预置低
A5	ESP32-S3 只有 2.4GHz，5G SSID 直接 WL_NO_SSID_AVAIL	连 2.4G
A6	把 85Hz 当可见刷新率（见第二节）	按「秒」设计，别按「赫兹」
A7	板子把 IO19 给了 3 个 ADC 按键，而 S3 原生 USB 要吃 IO19/20 → 原生 USB 不可用。「USB 传数据」其实就是 CH340 串口	GPIO 预算要同时绕开 16 位并口和按键，没有第二条数据通路

B epdiy 库层（读源码，别凭记忆）

#	坑	修法 / 判据
B1	dirty_lines 是 malloc() 出来从不清零——初始化不清、每次刷完也不清——而 epd_difference_image_base() 只重算本次 area 覆盖行的 dirty 标记。残留的 dirty 行就拿 difference_fb 里的旧差分数据去驱动波形 → 随机黑白块，块边界正好对齐 tile/area。这就是斑马纹的底层机制	GC16 一律扩整屏（让所有行重算）；每次局部刷新前 memset(hl.dirty_lines, 0, …) 预清零
B2	epd_write_string 默认不画背景（EPD_DRAW_BACKGROUND 没置位，只写前景字形像素）。旧内容留在帧缓存里，差分认为「没变」就永不刷 → 永久重影	每帧开头整幅清白（epd_fill_rect(full_screen, 0xF0)）。零性能损失：差分只送变化行
B3	「局部 + GC16」画不全（见第二节）	模式 × 路径逐格单独验证
B4	固件只在开机画面写了字，首帧后再不碰帧缓存。主机差分只跟自己上一帧比，固件画过、主机不知道的东西永远擦不掉	固件改屏必须让主机也知道（或渲染前全清）
B5	字体只带 ASCII，中文渲染成空白/方块	屏上文案只用英文
B6	epdiy 必须配核心 2.0.x：它的 pca9555.c 用了 #include <driver/i2c.h>（IDF legacy I2C 驱动），3.x 已删除	锁死核心 2.0.14；升级前先确认这个 legacy API 还在不在

C 固件应用层

#	坑	修法 / 判据
C1	g_first（首帧强制 GC16）每次清屏后都被置回 true → 主机发的 DU 被固件悄悄升级成坏的「局部 + GC16」路径，主机侧的修复被完全抵消	删掉一切「固件自作主张改刷新模式」的逻辑，模式完全由数据/flags 决定。判据：日志出现 mode=2（GC16）而主机明明发的是 DU flag——注意固件枚举（DU=1/GC16=2/GL16=5）和协议 flag（0x02=DU）是两套不同的数字
C2	HardwareSerial::begin(baud, config, rx, tx) 参数顺序是先 RX 后 TX。我按直觉写成 (…, TX, RX) → 固件 TX 顶到 CH340 自己的 TXD，两边对顶。极具迷惑性：能收帧、能刷屏，但日志/ACK 一句都上不来	按 RX, TX 顺序传（本板 TX=GPIO43 / RX=GPIO44）
C3	USB CDC 的日志字节被泵进了同一个协议解析器 → 每次刷屏 USB 重枚举都投杂散字节，整帧错位。坏帧率 45%→80%	非传输通道的字节流一律不许进解析器
C4	1MB 收帧缓冲放内部 RAM 挤爆堆	ps_malloc 进 PSRAM
C5	固定 x 落笔的文字（时间/数值）字宽一超就出画	epd_get_text_bounds() 先量实际字宽再落笔（从右边缘右对齐）
C6	固件链路看门狗 12s：服务端任何静默 > 12s 就拆链	服务端保证任何一次静默 < 12s（批内每 ~4s 回一次 ACK）
C7	固定超时是错的：整屏帧光发送就要 11.3s，固定 2s 超时必然误判重传 → 死循环	超时按帧长自适应：max(基础值, 字节数/(波特率/10) + 基础值)
C8	掉一个字节就永久失联，除非有两套恢复机制：① 空闲 100ms 丢半截帧（不丢的话之后每次重传的帧头都会被当 payload 吞掉 → 死锁）；② 伪同步 22 字节重扫（帧头 CRC 不符时把已消费的字节重新扫一遍，救回被噪声偷走的真帧头）	两套都要。UART0 与启动日志共线，还要加抗噪（magic 重同步 + 双重 CRC + 整帧校验通过才 ACK）

D 服务端 / 部署层

#	坑	修法 / 判据
D1	pkill -f epd_serve.py 把自己所在的 shell 也杀了（cmdline 含同一串）→ 输出全空、进程「起不来」	[e]pd 括号技巧，或 ss -ltnp 取 pid 再 kill <pid>
D2	SSH 里 nohup & 起的后台进程随会话死（systemd 用户 Linger=no）	tmux new -d -s epd '… \| tee log' 分离常驻（后来迁到 systemd service，见第五节）
D3	CPU 差分公式：busy ≠ 各列求和，而是 total − (idle + iowait)。写错时空载恒显 ~50%。判据：「每核全 50% 但 load 只有 0.1」的矛盾	busy = 总时间 − idle − iowait
D4	Arch 的串口组是 uucp（不是 Debian 的 dialout）	usermod -aG uucp <user> 重登录
D5	开机 WiFi.scanNetworks() 饿死 IDLE(core0) → task_wdt abort 重启循环	别开机扫描，直接 WiFi.begin(ssid, key)
D6	「静默 80ms = 批末」的判定是错的——链路抖动被当批末 → 巨型 GC16 → 板子卡死在刷屏里	显式发 PING 帧标记批末；兜底空闲阈值放宽到 1500ms
D7	清屏帧回两条 ACK，没收干净后面所有 ACK 索引整体错位	逐条对齐收
D8	glob("/sys/class/drm/card[0-9]*") 会把 card0-DP-4 也算进来 → 双卡只读到一张	re.fullmatch(r".*/card\d+", path) 过滤
D9	sysfs 的 cardN 顺序和 rocm-smi 的 GPU[x] 是反的（而且本机物理下层那张卡散热更好）。按 rocm-smi 序号写标签会把 GPU 标反	别抄 rocm-smi 的编号，先搞清映射
D10	整屏 1MB 帧必被固件当「半帧」丢掉（dropped a half frame）	整屏重画切 64×64 tile 逐块发，固件自动合并成一次大刷新

---

四、架构转向（真正的教训）

第一版是推像素的：服务端 PIL 渲染、差分成 64×64 tile 推过去，配 ARQ 补发、看门狗、批时序。能跑——直到斑马纹 bug 出现，我花了一整天追。

排障过程中反复出现同一类症状：「主机和固件对同一状态的理解不一致」（谁定 GC16、ACK 收到第几条、什么算批末）。这是分布式状态一致性问题，说明职责切错了地方。

于是我把整条像素通路砍了，切到终端模型：服务器发一行数据，ESP32 本地渲染、本地决策。

	推像素（旧）	终端模型（现）
链路负载	整帧 1MB / 差分几十 KB	~100–250 B/s（一行 ASCII 键值）
渲染	服务端 PIL	ESP32 本地（fill_rect + write_string——btop 看板就是矩形 + 字）
刷新决策	跨网络协调（flags/ARQ/看门狗/扫屏时序）	纯固件本地
改 UI	改 Python 就行	改 C++ 重烧（换稳定性的代价）

把控制面（刷新决策、状态同步）收到离屏最近的一端之后，网络上只剩数据面——复杂度按数量级下降。1MB 缓冲、ARQ、看门狗、扫屏切块、USB 掉线 workaround 全都不存在了。

沉淀出来的一条经验：当排障已经把故障面收窄到一小撮已知嫌疑时，估算「绕过这条路径」的成本 vs「复现→定位→修复」的成本——绕过去往往更快。这里绕过的成本 = 加一个帧类型 + 一个小渲染引擎 + 一个小采集器（约半天），比把像素通路查穿便宜，而且顺手消灭了一整类问题。

同阶段还有两个值得带走的手法：

• 隔离自检（本地复现法）：做 5 个固件自检阶段（ST1~ST5），每条生产路径都在固件本地复现一遍，数据全本地生成（排除网络/协议/传输），一次烧录分辨全部嫌疑。每条自检只和上一条差一个变量。当「本地自绘」永远干净、只有「网络推送」出斑马时，故障面一下午就劈到网络数据面了。自检做成编译开关（-DEPD_SELFTEST）常驻代码——屏上再出任何异常，先跑一遍。
• 远程判屏：人不在屏前的时候，手机拍照 → 二值化 → 按列算暗占比 → 跑游程 RLE：黑白块宽是 tile 尺寸的整数倍 ⇒ 差分/合并层的锅；不是 ⇒ 波形/面板层的锅。屏上留四角角标当坐标标尺；本机把发出去的 tile 解回像素量黑占比，判「发送端是否无辜」。

---

五、不性感但致命的运维细节

• 版本锁死写进文档。核心 2.0.14 + epdiy 2.0.0 不是随便能换的——升级前先确认 legacy I2C API 还在。
• 自检代码是资产不是垃圾，留宏开关常驻。
• 数据协议宁 ASCII 不二进制：一行可 grep、人眼可读、CRC 照挂的键值，在这个带宽下比紧凑二进制强——带宽预算宽裕时，可调试性 > 字节数。
• 服务端采集纯标准库：/proc + sysfs 不需要 psutil，scp 一个文件就能跑。
• 服务端做开机自启：最后是 systemd unit（Restart=always）。实测服务器掉电重启后拿到的 IP 一晚上漂了三次，板子 15s 内自己连回。当前拓扑里板子先连到一台常开的笔记本（portproxy 转发到服务器），我计划把服务器网线直插路由器 LAN 口去掉这一跳。
• 凭据放仓库外：WiFi 凭据放在 git/网盘之外的头文件，编译 -I 引入。
• GPU 数据全走 sysfs，不起子进程、不用 root：gpu_busy_percent、mem_info_vram_used/total、hwmon 温度/功耗/风扇/频率——比 shell 出 rocm-smi 轻得多。（AMD 是 rocm-smi/sysfs，不是 nvidia-smi。）

---

六、下一步

• GPU 信息再加细（per-process 级别，向 nvtop 看齐）；板子直连服务器（去掉转发这一跳），整系统收敛成两节点。
• 静态层缓存 + 元素级脏重绘：真要往 2s 节奏以上提刷新时再上（内存还有 ~5MB PSRAM、~13MB flash 富余，唯一潜在瓶颈是 CPU 时间——触发线没到之前不优化）。
• 长期跑下来如果 DU 残影累积明显，再调 GC16 频率或把灰度内容切 GL16。

---

一句话总结

做「显示终端」，就让它当终端：渲染和刷新决策放在离屏最近的地方，网络只走数据。

有问题欢迎留言，帧协议和自检设计都可以聊。想看完整源码的（固件 + 协议 + 服务端 + 自检序列），评论区留言，我看到会发。

---

直接 github 上开源啊. 搞一个按钮可以在多台服务器之间 toggle. 这样一屏监控多机...