上一篇介绍 r730xd-fan-control 的时候，它还只是「能看温度、能调速、能一键恢复自动温控」。一个月过去，Web 版做到了 v0.4.1，已经通过正式的离线 installer 跑在家里的 OpenWrt 路由器上。
功能上的变化一句话说得完：遥测历史落到 SQLite，容器重启不再清零，趋势可以看 5 分钟到 24 小时；桌面版和 Web 版统一成近黑单色界面，颜色只用来表示报警，琥珀是 warning，红是 critical，其余地方一点饱和色都不留。
真正值得写下来的是另外三件事。它们指向同一个判断：一个运维界面显示错的数字，比显示「读不到」要糟糕得多。
第一件是功耗页上的 0 W。iDRAC 的 Redfish 接口有一组 PowerMetrics 字段，本该给出平均、最小、最大功耗，但这台 R730xd 的 iDRAC8 返回的是一串全零。界面老老实实把它画了出来，于是首页写着「平均 0 W」——而同一个页面的实时读数是 133 W。两个数字都来自同一台机器，同时挂在屏幕上互相打脸。
修法不是去猜一个合理值填进去，而是把这三个无效字段直接从下发数据里删掉，改用本地已经存下来的历史样本自己算，并且在旁边写清楚它是怎么来的：「按当前趋势区间（5 分钟）的 11 个图表样本计算 · iDRAC 未提供有效数值」。数字变成了 131.6 / 129 / 134 W，更重要的是读它的人知道这是谁算的、基于几个样本。
第二件是完整 SDR 扫描。ipmitool 1.8.19 在这台 iDRAC8 2.70 上读到一半会 SIGSEGV 直接崩掉。可选的做法有三种：假装成功、整个报失败、或者保留崩溃前已经拿到的 83 条并明确标成 partial。选了第三种，但界面上必须写明它是部分结果——因为「83 条传感器数据」和「这台机器有 83 个传感器」是完全不同的两句话，前者有用，后者是谎。至今这条路还没走通，扫描仍然只能给部分数据，项目文档里也就这么写着，没有升级成「已支持完整扫描」。
第三件是我自己判断错了。部署几次之后路由器的 overlay 空间从 358 MB 掉到 276 MB，我认定是每次升级留下的 rollback 镜像标签堆积，还把这个结论写进了证据记录。后来动手删掉 5 个标签，实测可用空间从 276.4 MB 变成 276.9 MB——几乎没动。原因很简单：那些是指向同一批镜像的标签，不是独立镜像，解标签当然不释放空间。真正吃掉那 80 MB 的是「在目标机上原生构建」这条路线本身，构建必然拉取基础镜像并留下它的层。
于是回去把原来那条结论标成「归因错误」，另起一条写清楚正确的解释和实测数据，旧的一行不删。留着它，是因为下次再遇到类似现象时，「我曾经这样猜过而且猜错了」比一条干净的正确答案更有价值。顺带一提，同一轮清理里 /tmp 从 205.8 MB 降到 2.9 MB，而路由器上的 /tmp 是 tmpfs——那 200 MB 一直占的是内存。
这三件事没有一件是新功能。但一个长期挂在屏幕上的运维工具，可信度就是从这些地方一点点攒起来或者漏掉的。工具敢说「我不知道」，人才敢信它说「一切正常」。
项目源码、Windows GUI、OpenWrt Docker 部署说明都在：