datocp

嘿嘿，想当年收集了 30 个网络设备，后来运营商加入，很多新设备 100 块都不用。扔了可惜，拿着吃灰。

工厂的概念，投资新设备赚更多的钱。

我考虑的主要还是吃灰问题，没用的东西买来占地方。

还是错的。。。

这几天调试 excel 宏，靠问答式真不行，才没几次之前完好的功能又废了。
还是得按 gemini 的格式把实现的一项项逐一列上去，才能更好的调用它工作。不然错来错去，都不知道错在哪里。

最近接收日志，才发现 openwrt 有大量的 dhcp 不同握手阶段类型的日志。
超时以前理解为 ip 池不够用，或者 dhcp 消亡时间长达 3 个月，导致无 ip 可分配。tplink 的 ap 有终端数限制，会出现这个下那个上的情况。
才发现会出现 wrong address 。而且是在 dhcp 2 小时的消亡时间大概是刚过 50%，据说还有个 75%的说法。可能是因为 ip 不够分配，dnsmasq 基于某种机制，竟然将这个才分配 1 小时不到 2 小时的 ip 又分配给其它终端。。。交换机都提示有 2 个不同 mac 用了同样的 ip 。

ai 时代确实不一样

上次给小朋友介绍 豆包爱学，那就是位和蔼可亲的老师，又能解题又能出题，小朋友和它对话的很开心。。。我的想法简单到买个 11 寸平板装上豆包爱学就好，其它的就是画画用。

还是水平太菜，不会用。。。
之前学习过用文本定义来让 gemini 高效运行，可能不会用效果比较差。
平时简单的对话 gemini 写，我来反馈运行结果，昨天给它限定了 server2019 它才写了适用的代码。

先说说你有多少钱，
有人有几百万花不光的感觉
有人月光族

今天 gemini 又写了好几个 final 又 final ，好几遍才通过。
即便是才 500 行的代码，需求还是人提供的。AI 根本不会提供 100%高效的代码。
就这么个日志呈现系统，每天发现点新问题。AI 自己都没经过测试 final 又 final N 遍也是很服。缺乏相关经验，惊艳于 AI 代码能力，细节仍得精敲细打。

回顾今天（ 2026 年 11 月 04 日）我们在本项目中协同推进的核心修改和功能迭代，主要完成了以下 4 项关键优化：
* 锚点架构回退与历史归档回溯（$historyDaysBack ）
* 将 PowerShell 脚本回退到了最稳定的 2026-11-04 经典底座，彻底移除了所有容易在 Windows Server 2019 (PowerShell 5.1) 环境下引发 Unexpected token '}' 解析报错的嵌套函数和三元运算符。
* 实现了跨天多文件归档日志的自动回溯与合并加载（支持配置 $historyDaysBack = 3 ，在重启时自动按时间先后顺序合并前 3 天的归档日志与今天的实时日志）。
* 保留核心保障机制
* 确保了 Instant Rotate “用完即放”（ Poll & Release ）架构的稳定运行，流式读取后立刻 Dispose 关闭文件流，99.9% 的时间文件无锁，完美放行 Visual Syslog 的日常自动 Rotate 归档重命名。
* 维持了 ConcurrentQueue 环形队列硬隔离与周期性 [System.GC]::Collect() 垃圾回收机制，使监控系统长期运行时的内存稳稳锁定在 100MB 级别。
* OpenWrt 与华为交换机时间戳格式强归一化
* 解决了 OpenWrt （原生双空格如 Nov 4 ）与华为交换机（单空格如 Nov 04 ）时间格式不统一的问题。
* 在 logdy.config.json 的解析中间件中加入了强力的时间规范化逻辑，自动将单/双空格及个位数日期补零，统一转换为标准双字符格式（如 Nov 04 10:35:19 ）。
* Logdy 全局搜索框精准命中优化
* 为了彻底解决在 Logdy 搜索框无法通过 Nov 04 搜到 OpenWrt 日志的痛点，直接在中间件底层对 line.content 原始内容进行了原地替换（ Normalized ）。
* 现在无论是前端表格展示，还是顶部的全局关键词搜索（输入 Nov 04 ），都能百分之百跨设备精准命中所有厂商的日志。

晕，这是多少年前的帖子。
mesh 本来就是网状，难得观察到华为交换机将端口关闭，但 poe 供电仍在，mp 接在交换机的有线链路断开，数据只能借无线的 mesh point 接口进行上联。

实际有线 mesh A+B 2 个 mp,它们各自通过 br-lan 连接交换机，同时又桥接到 mesh point 通过 mesh point 接口又建立了一条无线链路。