4.2 英寸电子纸信息终端

把一天的信息，留在一张安静的屏幕上。

ESP32-S3 驱动的 400 × 300 电子纸原型，把天气、摘要、日历与待办放进桌面。沿着 Web / BLE、数据整理、Paint 和 epd_flush，记录信息怎样成为一张可读的画面。

实物原型 · 持续完善已核对当前源码、开发日志与已有原型资料；本次未重新编译、烧录或测量刷新与续航。

桌面需要的，可能只是一眼。

InkFeed 从桌面信息终端出发：天气、今天的安排和一小段摘要，应该在抬头时就能看到。4.2 英寸电子纸的有限空间迫使内容做取舍，也让“什么值得留下来”成为界面设计的一部分。

工程已有实物原型与演示素材。这里把当前源码中的显示、连接与内容链路整理成档案，重点是让每一条信息都能解释从哪里来、怎样画出来、何时更新。

当前工程以 ESP32-S3、ESP-IDF 与 SSD1683 组件组织显示，画面尺寸在 Paint 头文件中定义为 400 × 300。UI 使用自己的页面状态机，文字、线条与图标通过 Paint 绘制，再进入显示更新路径，没有套入 LVGL。

构建清单包含 Web 服务、BLE 命令、联网获取、本地存储与多个页面模块。首页把天气、备忘录和热点组合在一起，日历、课程、图片和阅读等内容进入独立页面；配置端与屏幕端各自承担适合自己的工作。

2026 年 6 月的开发日志记录过一个细节：大字温度与温度区间对不上，生活提醒又重复了温度。问题跨过接口、模型响应和 UI 三层，不能只凭屏幕现象判断是排版错误。

处理时先保住 Open-Meteo 已提供的有效温度，让 DeepSeek 只更新摘要，再通过摘要过滤和 UI 日志追踪传入值。同一轮排查还发现数字 9 的字体位图问题。看似相同的“数字不对”，实际来自两条不同链路。

电子纸有自己的更新节奏。版面先决定读什么，绘制层负责画面，刷新层再决定怎样提交；这种分工让内容修改不必直接侵入面板时序，也让显示问题能够逐层定位。

生成摘要适合压缩信息，但不应顺手取得事实字段的覆盖权。当前源码保留了天气获取失败时的生成数据回退分支，后续还需要更清楚地表达来源与失败状态。界面上的一行文字，应有与它可信程度相称的位置。

当前源码能看到 Web / BLE 入口、天气与摘要整理、页面切换、本地存储以及 Paint 到电子纸的完整组织方式。已有原型素材说明设备形态，开发日志留下真实修正过程，两者承担不同的证据角色。

这次网站整理核对了这些资料，没有重新运行固件，也没有复测不同刷新模式。续航、残影、刷新耗时与长时间联网恢复，仍应由同一硬件、同一版本和明确条件下的记录回答。

接下来优先整理页面和内容来源的状态表达：联网失败时保留什么，摘要过期时怎样提示，长文本怎样裁切，BLE 与本地操作同时发生时由谁决定最终页面。

显示验证将单独记录面板版本、固件版本、刷新策略、环境与观察结果。让照片、日志和源码能够互相对应，InkFeed 的下一步才不只是一张更好看的桌面图。

每一步，都有自己的问题。

过程记录 01 · 2026 年 6 月的开发日志记录过一个细节：大字温度与温度区间对不上，生活提醒又重

过程记录 02 · 处理时先保住 Open-Meteo 已提供的有效温度，让 DeepSeek 只更新摘

选择模块，看看它负责什么。

Web 与 BLE 提供配置和内容入口，联网数据经过解析与组织。天气数值与生成摘要保留各自来源。

逻辑关系示意；不表示完整电路、接线或实时硬件数据。

原理、排障与工程取舍。