1. 项目概述：为什么这两个 Hermes Agent 开源项目突然火了？

最近在技术社区里，“Hermes Agent”这个词出现频率高得有点反常——不是某家大厂新发布的商业产品，也不是某个学术论文里的冷门概念，而是实实在在跑在开发者本地机器、树莓派甚至工控机上的轻量级代理服务。而真正把这股风刮起来的，是两个几乎同期冒头、风格迥异却高度互补的开源项目：“橙皮书”和“Web UI 监控面板”。它们不约而同地踩中了当前一线开发与运维人员最真实的痛点：既要快速接入设备/服务做协议桥接与状态透出，又不想被厚重的平台框架绑架；既要实时看到数据流和命令执行痕迹，又拒绝写一堆前端代码去搭监控页。

“橙皮书”这个名字乍听像本技术散文集，实则是个极简但极其扎实的 Hermes Agent 核心运行时——它用 C# 编写，专为 Windows 和 .NET 6+ 环境深度优化，支持串口（COM）、TCP/UDP、Modbus RTU/TCP、CAN FD（通过 USB-CAN 适配器）等工业现场高频协议，同时内置轻量规则引擎，允许你用 YAML 文件定义“当温度传感器读数 > 85℃ 时，自动触发继电器断电并推送告警到企业微信”。它不提供 Web 页面，也不带数据库，整个运行时内存占用稳定在 12–18MB，启动时间低于 380ms。我拿它在一台 i3-4170 的老旧工控机上连续跑了 17 天，没重启、没内存泄漏、没日志刷屏。

而“Web UI 监控面板”则是它的视觉搭档——一个纯前端 Vue 3 + TypeScript 实现的响应式控制台，不依赖 Node.js 运行时，直接通过 WebSocket 连接本地或远程的 Hermes Agent 实例。它能实时渲染设备拓扑图、协议会话流、命令执行历史、变量快照对比，甚至支持拖拽式创建简易逻辑块（比如“取 A 设备的值 × 1.2 + B 设备的偏移量 → 写入 C 寄存器”）。最关键的是，它完全静态部署：你把它丢进 Nginx、Caddy 或任何 HTTP 服务器根目录，改一行配置指向你的 Agent 地址，刷新页面就可用。没有构建步骤，没有 npm install，没有 node_modules 占用 2GB 磁盘。

这两个项目之所以“超火”，根本原因在于它们共同完成了一次精准的“能力解耦”：橙皮书负责稳、准、快地干活（协议解析、指令调度、异常熔断），Web UI 负责清、真、快地呈现（状态可视化、操作可追溯、逻辑可编排）。它们之间只靠一套精简的 JSON-RPC over WebSocket 协议通信，接口定义不到 20 个方法，文档全在 GitHub README 里，连 curl 示例都给你写好了。这不是又一个“大而全”的 IoT 平台，而是一对可以塞进产线调试笔记本、嵌入式网关、甚至学生课程设计板子的“数字扳手”——拧得紧、不打滑、用完就收。

如果你正面临这些场景：

• 需要快速把 STM32F407 开发板的 UART 日志转发到内网 Grafana；
• 在实验室用树莓派 Pico W 采集温湿度，再通过 Hermes Agent 推送到本地 MQTT Broker；
• 给客户交付一套“看得见、摸得着、改得了”的上位机系统，但预算只够买一块 Win10 平板；
• 或者只是想在宿舍里用 ESP32-C3 控制一盏 LED，并在手机浏览器里点按钮开关——
  那么，这两个项目就是你现在最该花 90 分钟认真看懂、亲手跑通的组合。它们不承诺替代 SCADA，也不对标 ThingsBoard，它们只承诺一件事：让你在今天下班前，把设备连上、数据看见、命令发出。

2. 核心设计思路拆解：为什么是 C# + Web 前端？而不是 Python 或 Electron？

2.1 橙皮书为何坚持用 C# 构建后端运行时？

很多人第一反应是：“工业协议处理？Python 不香吗？有 PySerial、pymodbus，生态多成熟。”这话没错，但成熟不等于合适。我在实际项目中用 Python 写过三套类似的串口代理服务，最后全换成了 C#，原因很实在，不是语言信仰，而是四个硬指标：

第一，确定性延迟。
Hermes Agent 的核心任务之一是“实时响应硬件事件”。比如某 PLC 的急停信号通过 DI 输入模块触发中断，Agent 必须在 ≤ 50ms 内捕获、解析、执行预设动作（如切断伺服使能）。Python 的 GIL 和垃圾回收机制会导致不可预测的毫秒级卡顿——我实测过，在树莓派 4B 上跑一个带 asyncio 的串口监听脚本，当系统后台有 apt-upgrade 下载包时，串口数据包到达间隔抖动高达 120ms，远超安全阈值。而橙皮书基于 .NET 6 的Span<byte>零拷贝解析 +System.IO.Ports原生驱动封装，同一硬件下平均响应延迟稳定在 8.3±1.2ms，P99 延迟 ≤ 15ms。这不是理论值，是我用 Logic Analyzer 实测 UART 引脚电平变化到 Agent 发出 TCP 包的时间戳差得出的数据。

第二，Windows 原生兼容性零妥协。
国内 80% 以上的产线调试、设备维保、教学实验环境，主力操作系统仍是 Windows 10/11。很多老设备的驱动（尤其是 USB-COM 转换器、PCIe CAN 卡）只提供 Windows INF 安装包，Linux 下要么没驱动，要么需要手动编译 DKMS 模块。橙皮书直接调用 Windows API 的CreateFileW打开 COM 口，用WaitCommEvent实现事件驱动，完全绕过跨平台抽象层。这意味着你插上一款“杂牌”CH340 串口线，不用装任何额外驱动（Windows 10 自带），双击HermesAgent.exe就能识别/dev/ttyUSB0对应的COM3——这种开箱即用的体验，是 Python 的pyserial.tools.list_ports.comports()永远给不了的，后者在某些 OEM 笔记本上会漏识别。

第三，部署即拷贝（XCOPY Deployment）的极致简化。
橙皮书发布包是一个独立的.zip，解压后只有 3 个文件：HermesAgent.exe、appsettings.json、plugins/文件夹。没有 MSI 安装器，不写注册表，不放 DLL 到 GAC。你想把它部署到客户现场的工控机？U 盘拷过去，管理员权限运行一次HermesAgent.exe --init生成默认配置，然后加到开机启动项（shell:startup）即可。整个过程不需要 .NET Runtime 预装——因为它是自包含发布（Self-Contained Deployment），.NET 6 运行时已打包进 EXE。我试过在一台刚重装完纯净 Win10、没装任何开发工具的机器上，从插入 U 盘到看到串口数据在控制台滚动，耗时 4 分 23 秒。而 Python 方案呢？先装 Python 3.11，再 pip install 一堆依赖，再处理 pywin32 权限问题……光环境准备就能卡住非技术人员。

第四，强类型约束带来的协议健壮性。
Modbus TCP 报文结构固定：6 字节报文头 + 1 字节单元 ID + 1 字节功能码 + N 字节数据。橙皮书用 C# 的struct显式定义ModbusTcpHeader，编译期就校验字段对齐、大小端、字节序。一旦收到非法长度的报文（比如头只有 5 字节），解析器直接抛InvalidDataException，不会像 Python 的struct.unpack('!6BH', data)那样静默截断或填充默认值导致后续逻辑错乱。我在测试某国产 HMI 屏幕时发现，它发送的 Modbus TCP 报文头第 5 字节恒为 0xFF（应为事务标识符），Python 版本代理误判为合法报文并继续解析，结果把后续所有寄存器读取都偏移了 1 字节；而橙皮书在ParseHeader()方法里第一行就if (header.TransactionId == 0xFFFF) throw new ProtocolViolationException();，立刻阻断错误传播。

提示：橙皮书不是排斥 Python，而是明确划清边界——它不做数据分析、不训练模型、不生成报表。那些事交给下游系统（如用 Python 写的 Flask 后端接收其 MQTT 数据）。它只做一件事：当物理世界发生变化时，以最确定的方式，把那个变化“翻译”成数字世界的标准消息。

2.2 Web UI 监控面板为何放弃 Electron，选择纯静态前端？

另一个常见疑问是：“既然叫 Web UI，为啥不直接做个 Electron 桌面应用？还能打包成 .exe，用户双击就用。”这个问题问到了关键。橙皮书团队在 v0.3 版本确实做过 Electron 尝试版，但两周后就废弃了，原因直击本质：

Electron 的“桌面感”是以牺牲“泛在访问”为代价的。
想象这个场景：你在车间调试一台 CNC 设备，手边只有一台 Android 平板（没装任何 APP）；或者你在客户会议室演示，投影仪连着一台 Mac，但客户 IT 政策禁止安装任何未签名的 .exe/.dmg；又或者你是个学生，在宿舍用 Chromebook 做课程设计。Electron 应用无法跨平台运行，更无法在这些受限环境中打开。而纯静态 Web UI，只要设备有浏览器（哪怕是 IE11，它也做了兼容），输入http://192.168.1.100:5001就能进入控制台——这才是真正的“ anywhere, any device”。

体积与启动速度的碾压式优势。
Electron 最小化打包后，一个空壳应用也要 120MB+（含 Chromium 内核）。而 Web UI 监控面板的完整生产包（含所有 Vue 组件、ECharts 图表、WebSocket 客户端）压缩后仅 1.8MB，Gzip 后 620KB。我用 Chrome DevTools 模拟 3G 网络（1.6Mbps，500ms RTT）加载它，首屏渲染时间 1.2s；而同等网络下加载 Electron 的主进程（需下载整个 Chromium 沙箱）平均耗时 8.7s，且首次启动有明显白屏。对于需要快速查看设备状态的场景（比如判断 PLC 是否在线），1 秒和 8 秒，体验天壤之别。

安全模型的天然契合。
Hermes Agent 默认只监听本地回环地址127.0.0.1:5000，Web UI 作为静态资源，由独立的轻量 HTTP 服务器（如 Caddy）托管在127.0.0.1:5001。两者同源（都是 localhost），WebSocket 连接无需跨域配置。而 Electron 应用运行在 Node.js 环境，若直接new WebSocket('ws://localhost:5000')，会触发 Node.js 的 CORS 检查（尽管是本地地址），必须额外配置webPreferences: { webSecurity: false }，这等于主动关闭安全沙箱——在工控环境里，这是不可接受的风险。纯前端方案则完全规避此问题，浏览器的安全策略天然保护了 Agent 的本地 API。

维护成本的指数级下降。
Electron 需要同步维护主进程（Node.js）、渲染进程（HTML/CSS/JS）、以及两者的 IPC 通信协议。每次升级 Electron 版本，都要重测所有 IPC 接口是否断裂。而 Web UI 监控面板只维护一套前端代码，API 全部走标准 HTTP/WebSocket，与后端解耦彻底。当橙皮书在 v1.2 版本将 JSON-RPC 协议从 v1 升级到 v2（增加批量调用支持）时，Web UI 只需修改 3 行apiClient.ts代码，重新构建发布，旧版 Agent 仍可兼容（通过协议版本协商）。这种松耦合，是 Electron 架构永远做不到的。

注意：它不是“不要桌面”，而是“桌面能力下沉”。橙皮书本身已提供 Windows 服务安装、Linux systemd 单元文件、macOS launchd 配置模板。Web UI 只是你的“操作界面”，不是“运行载体”。你可以把它部署在树莓派的 Caddy 上，用手机扫二维码访问；也可以把它集成进你现有的 React 管理系统里，作为一个 iframe 嵌入；甚至可以用npx serve -s dist在本地临时起一个服务——它存在的唯一目的，就是让你用最顺手的设备，看到最需要的信息。

3. 核心细节与实操要点：从零部署橙皮书 + Web UI 的完整链路

3.1 环境准备与最小可行验证（5 分钟搞定）

别急着看文档、别急着改配置。先用最原始的方式，确认两个项目能在你机器上“活过来”。这是所有后续工作的基石，跳过这步，后面 90% 的问题都源于环境误判。

第一步：下载与解压（Windows 示例）

• 访问橙皮书 GitHub Releases 页面（https://github.com/hermes-agent/orange-book/releases），下载最新版HermesAgent-v1.4.2-win-x64.zip。
• 新建文件夹C:\hermes\orange，将 ZIP 解压至此。你会看到：

  C:\hermes\orange\ ├── HermesAgent.exe ├── appsettings.json └── plugins\

• 同样，访问 Web UI 监控面板 Releases（https://github.com/hermes-agent/webui-dashboard/releases），下载webui-dashboard-v2.1.0-dist.zip，解压到C:\hermes\webui。你会看到：

  C:\hermes\webui\ ├── index.html ├── assets\ └── favicon.ico

第二步：启动橙皮书，观察默认行为
以管理员身份打开 PowerShell（右键开始菜单 → Windows PowerShell（管理员）），执行：

cd C:\hermes\orange .\HermesAgent.exe --verbose

你会看到类似输出：

[10:23:42 INF] Starting Hermes Agent v1.4.2... [10:23:42 INF] Loaded configuration from 'appsettings.json' [10:23:42 INF] HTTP API server listening on http://127.0.0.1:5000 [10:23:42 INF] WebSocket server listening on ws://127.0.0.1:5000/ws [10:23:42 INF] No devices configured. Waiting for dynamic registration...

关键信息有三点：

• 它已启动，HTTP API 和 WebSocket 都在127.0.0.1:5000监听；
• 它没报错，说明 .NET 6 运行时已就绪（Win10 1809+ 自带，旧系统需单独安装）；
• 它提示“No devices configured”，这是正常现象——默认配置是空的，等着你告诉它连什么设备。

实操心得：如果这里报错The specified module could not be found.，99% 是缺少 Visual C++ 运行库。去微软官网下载vc_redist.x64.exe安装即可。别试图用 SxS 清单解决，太折腾。

第三步：用浏览器直连 API，验证通信通路
打开 Chrome 或 Edge，访问http://127.0.0.1:5000/api/v1/status。你应该看到一个 JSON 响应：

{ "version": "1.4.2", "uptimeSeconds": 127, "deviceCount": 0, "activeConnections": 0, "memoryUsageMB": 14.2 }

这证明：

• Agent 的 HTTP 服务工作正常；
• 你的浏览器能访问本地服务（排除防火墙拦截）；
• API 路由已注册（后续 Web UI 就靠它拉取基础状态）。

第四步：启动 Web UI，建立 WebSocket 连接
现在，你需要一个 HTTP 服务器来托管index.html。最简单的方法是用 Python（如果你有）：

cd C:\hermes\webui python -m http.server 5001

或者，更推荐用 Caddy（轻量、跨平台、配置即代码）：

• 下载 Caddy 2（https://caddyserver.com/download），解压后得到caddy.exe；
• 在C:\hermes\webui下新建Caddyfile，内容为：

  :5001 { root * C:\hermes\webui file_server }

• 运行caddy run。

然后，浏览器访问http://127.0.0.1:5001。页面加载后，右下角状态栏会显示Connecting to ws://127.0.0.1:5000/ws...，几秒后变成Connected (v2.1.0)。此时，页面中央的“设备列表”是空的，但左上角的 Agent 版本、运行时间、内存占用，已实时从 API 拉取并显示——WebSocket 连接成功！

提示：如果状态栏一直显示Connection failed，请打开浏览器开发者工具（F12）→ Console 标签页，看是否有WebSocket connection to 'ws://127.0.0.1:5000/ws' failed错误。常见原因：

• 橙皮书没在运行（检查 PowerShell 窗口是否关闭）；
• 端口被占用（用netstat -ano | findstr :5000查看 PID，再用任务管理器结束）；
• 浏览器扩展拦截（如 uBlock Origin，临时禁用试试）。

3.2 配置一个真实设备：以 USB-TTL 串口调试为例

现在，我们让橙皮书真正“干活”。目标：将一个 CH340 转 USB 串口模块（接在COM4）的数据，实时转发到 Web UI 的“串口监视器”面板，并能从 Web UI 发送命令回写。

第一步：物理连接与驱动确认

• 将 CH340 模块的 TX/RX/GND 接到你的 MCU（如 ESP32）的 RX/TX/GND；
• 电脑上打开设备管理器，确认COM4存在，且无黄色感叹号；
• 用串口助手（如 XCOM）向COM4发送AT\r\n，确认 MCU 有响应（如返回OK），证明硬件链路畅通。

第二步：修改橙皮书配置，添加串口设备
编辑C:\hermes\orange\appsettings.json，找到"Devices"数组，添加一个SerialPortDevice：

{ "Devices": [ { "Name": "ESP32_Debug", "Type": "SerialPort", "Configuration": { "PortName": "COM4", "BaudRate": 115200, "DataBits": 8, "Parity": "None", "StopBits": "One", "ReadTimeoutMs": 500, "WriteTimeoutMs": 500 }, "PollingIntervalMs": 100, "AutoReconnect": true } ] }

参数详解：

• "PortName": "COM4"：Windows 下必须写COMx，Linux 写/dev/ttyUSB0，macOS 写/dev/cu.usbserial-XXXX；
• "BaudRate": 115200：必须与 MCU 设置一致，否则乱码；
• "ReadTimeoutMs": 500：每次读取最多等 500ms，避免阻塞主线程；
• "AutoReconnect": true：如果拔掉 USB 线，Agent 会每 5 秒尝试重连，插回去自动恢复——这对现场调试至关重要。

第三步：重启橙皮书，观察日志
关闭之前的 PowerShell 窗口，重新运行：

.\HermesAgent.exe --verbose

日志中会出现：

[10:45:22 INF] Registered device 'ESP32_Debug' (SerialPort) [10:45:22 INF] Opening serial port 'COM4' at 115200 bps... [10:45:22 INF] Serial port 'COM4' opened successfully.

如果报错Access to the port 'COM4' is denied，说明端口被其他程序（如 XCOM）占用了，关闭它即可。

第四步：在 Web UI 中启用串口监视器
刷新http://127.0.0.1:5001，左侧导航栏会出现ESP32_Debug设备卡片。点击它，进入详情页，切换到Serial Monitor标签。你会看到：

• 实时滚动的串口接收数据（UTF-8 解码，支持中文）；
• 底部输入框，可输入命令（如AT+RST），按回车即发送；
• 右上角有“清除缓冲区”、“保存日志到文件”按钮。

现在，用手机热点连上 ESP32，让它打印WiFi connected, IP: 192.168.4.1，你将在 Web UI 里实时看到这行字——这就是你第一个真正跑通的 Hermes Agent 场景。

注意事项：

• 串口数据默认按行解析（\r\n或\n结尾），如果 MCU 发送的是二进制帧（如 Modbus），需在配置中设置"LineEnding": "None"，并启用"BinaryMode": true，此时 Web UI 会以十六进制显示；
• Web UI 的发送框默认追加\r\n，如果 MCU 不需要，可在设备配置中设"SendLineEnding": false；
• 如果看到大量??或乱码，90% 是编码问题。在 Web UI 的串口监视器右上角齿轮图标里，将字符编码从UTF-8切换为GBK（中文设备常用）。

3.3 进阶配置：用 YAML 规则引擎实现自动告警

橙皮书的真正威力，在于它内置的规则引擎。我们来做一个实战案例：当串口收到TEMP: 95.3°C时，自动触发蜂鸣器（通过 GPIO 控制），并推送微信消息。

第一步：确认硬件支持 GPIO 输出
橙皮书本身不直接操作 GPIO，但它支持通过SystemCommandPlugin调用外部程序。假设你有一块 Raspberry Pi 4B，已安装wiringpi工具，蜂鸣器接在 GPIO 18（BCM 编号）。先在 Pi 上测试：

gpio mode 18 out gpio write 18 1 # 蜂鸣器响 sleep 1 gpio write 18 0 # 蜂鸣器停

第二步：编写规则 YAML 文件
在C:\hermes\orange\plugins\rules\下新建temp_alert.yaml：

# 规则ID，全局唯一 id: temp_high_alert # 触发条件：匹配串口设备 ESP32_Debug 的接收数据 trigger: device: ESP32_Debug type: serial_received pattern: "TEMP: (?<temp>[0-9.]+)°C" # 执行动作 actions: - type: log level: Warning message: "High temperature detected: {{temp}}°C" - type: system_command command: "C:\\tools\\buzzer_on.bat" # Windows 下调用批处理 timeout_ms: 2000 - type: http_post url: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_WEBHOOK_KEY" headers: Content-Type: "application/json" body: | { "msgtype": "text", "text": { "content": "⚠️ 温度告警：{{temp}}°C\n设备：ESP32_Debug\n时间：{{now}}" } } # 规则启用状态 enabled: true

关键点解析：

• pattern: "TEMP: (?<temp>[0-9.]+)°C"使用命名捕获组(?<temp>...)，提取的温度值可在后续动作中用{{temp}}引用；
• {{now}}是内置变量，格式为2024-05-20 14:30:22；
• system_command动作在 Windows 下执行批处理，在 Linux 下可直接写gpio write 18 1；
• http_post动作用于推送企业微信，key替换为你在企业微信后台创建的 webhook 地址。

第三步：创建批处理文件（Windows）
新建C:\tools\buzzer_on.bat：

@echo off :: 模拟蜂鸣器响1秒 echo Buzzer ON > COM5 :: 假设你有一个 USB 蜂鸣器模块接在 COM5 timeout /t 1 /nobreak >nul echo Buzzer OFF > COM5 exit /b 0

（实际项目中，建议用更可靠的硬件方案，如继电器模块）

第四步：重启橙皮书，测试规则
重启 Agent 后，日志会显示：

[11:15:33 INF] Loaded rule 'temp_high_alert' from 'rules\temp_alert.yaml' [11:15:33 INF] Rule 'temp_high_alert' enabled and ready.

然后，用串口助手向COM4发送TEMP: 95.3°C，你会立刻听到蜂鸣器响，同时企业微信收到告警消息。规则引擎的执行延迟实测 < 15ms。

实操心得：规则调试是高频需求。橙皮书提供了--debug-rules参数：

.\HermesAgent.exe --debug-rules

此时，每当有数据触发规则，日志会详细打印：匹配了哪个 pattern、提取了哪些变量、执行了哪些 action、每个 action 的返回码。这是排查规则不生效的黄金开关。

4. 实操过程与核心环节实现：从单设备到多协议协同

4.1 构建混合协议拓扑：串口 + TCP + MQTT 三端互通

单一串口只是起点。真实工业场景中，设备协议五花八门。橙皮书的强大之处，在于它能把不同协议的设备，抽象成统一的“数据源”，再通过 Web UI 统一呈现和操作。我们来搭建一个经典拓扑：

• 边缘层：ESP32（串口）采集温湿度；
• 网络层：一台 Linux 服务器（TCP）运行 Modbus TCP 从站模拟器；
• 云平台层：本地 MQTT Broker（如 Mosquitto），接收汇总数据。

第一步：配置 ESP32 串口设备（已完成）
确保appsettings.json中已有ESP32_Debug设备。

第二步：添加 Modbus TCP 从站设备
在Devices数组中追加：

{ "Name": "Modbus_Slave", "Type": "ModbusTcp", "Configuration": { "Host": "192.168.1.100", "Port": 502, "UnitId": 1, "TimeoutMs": 3000, "RetryCount": 2 }, "PollingIntervalMs": 2000, "Registers": [ { "Address": 0, "Length": 2, "DataType": "Int32", "Name": "Temperature", "Description": "Current temperature in Celsius" }, { "Address": 2, "Length": 1, "DataType": "UInt16", "Name": "Status", "Description": "Device status flag" } ] }

说明：

• "Host": "192.168.1.100"是你的 Linux 服务器 IP；
• "Registers"定义了要轮询的寄存器地址、数据类型、别名。橙皮书会自动将Int32类型的0x0000001F（十进制 31）解析为31，并赋值给变量Temperature；
• 这些变量会自动注入到规则引擎的上下文中，供后续规则使用。

第三步：添加 MQTT 出站设备（用于数据上报）
再追加一个设备，类型为MqttPublisher：

{ "Name": "MQTT_Broker", "Type": "MqttPublisher", "Configuration": { "Broker": "tcp://127.0.0.1:1883", "ClientId": "hermes_agent_001", "Username": "", "Password": "", "KeepAliveSeconds": 60 } }

注意：这是一个“发布者”设备，不参与轮询，只负责接收其他设备的数据并转发。

第四步：编写跨设备规则，实现数据融合
新建C:\hermes\orange\plugins\rules\fusion_rule.yaml：

id: sensor_fusion trigger: # 当任意一个设备的数据更新时触发（串口或 Modbus） device: "*" type: data_updated # 但只在 ESP32 和 Modbus 都有有效数据时才执行 condition: "{{devices.ESP32_Debug.Temperature != null && devices.Modbus_Slave.Temperature != null}}" actions: - type: log level: Information message: "Fusing data: ESP32={{devices.ESP32_Debug.Temperature}}, Modbus={{devices.Modbus_Slave.Temperature}}" - type: mqtt_publish device: MQTT_Broker topic: "hermes/sensors/fused" payload: | { "timestamp": "{{now}}", "esp32_temp": {{devices.ESP32_Debug.Temperature}}, "modbus_temp": {{devices.Modbus_Slave.Temperature}}, "avg_temp": {{(devices.ESP32_Debug.Temperature + devices.Modbus_Slave.Temperature) / 2 | round(1)}} } qos: 1 enabled: true

这个规则实现了：

• 监听所有设备的data_updated事件；
• 用condition确保两个温度源都存在（避免空值计算）；
• 计算平均值并四舍五入到 1 位小数；
• 通过mqtt_publish动作，将融合后的 JSON 发布到hermes/sensors/fused主题。

第五步：在 Web UI 中创建融合仪表盘

• 进入 Web UI，点击右上角+ New Dashboard；
• 添加一个Gauge组件，数据源选择MQTT_Broker，Topic 填hermes/sensors/fused，Value Path 填$.avg_temp；
• 再添加一个Table组件，同样订阅hermes/sensors/fused，列配置为Timestamp: $.timestamp,ESP32: $.esp32_temp,Modbus: $.modbus_temp；
• 保存后，你将看到一个实时更新的融合仪表盘，数据来自两个完全不同的协议栈。

提示：Web UI 的 MQTT 订阅功能，是它与橙皮书深度协同的体现。你无需在橙皮书里配置 MQTT 订阅（那属于“下行控制”），Web UI 自己就能订阅任意 MQTT 主题，把第三方数据（如 Grafana 的告警消息）也拉进来，形成统一视图。

4.2 Web UI 高级技巧：自定义组件与离线缓存

Web UI 的强大，不仅在于开箱即用，更在于它为二次开发留出了清晰的入口。

自定义 Vue 组件注入
假设你需要一个专门显示 CAN 总线错误帧的组件。Web UI 支持在src/plugins/目录下添加自定义 Vue 单文件组件（.vue），并在main.ts中注册。但更轻量的方式是利用其Custom HTML Widget功能：

• 在仪表盘编辑模式，添加一个Custom HTML组件；
• 在 HTML 内容中，写入：

  <div id="can-error-widget"> <h3>CAN Bus Error Count</h3> <p>Errors: <span id="error-count">0</span></p> </div> <script> // 监听橙皮书的 WebSocket 事件 window.hermesApi.on('device:Modbus_Slave:status', (data) => { if (data.errorCount) { document.getElementById('error-count').textContent = data.errorCount; if (data.errorCount > 10) { document.getElementById('error-count').style.color = 'red'; } } }); </script>

这样，你就能在不修改 Web UI 源码的前提下，快速集成定制逻辑。

强制离线缓存策略
很多现场环境网络不稳定。Web UI 默认使用Cache-Control: no-cache，每次刷新都重新拉资源。你可以通过 Caddy 的header指