Hubitat Local MCP Server

Hubitat MCP 服务器

本地人 模型上下文协议（MCP） 直接在Hubitat Elevation集线器上运行的服务器。这不是在另一台机器上运行单独的Node.js服务器，而是在集线器本身上本地运行——有一个内置的规则引擎和103个MCP工具（36个 tools/list 通过类别网关）。

测试版软件：这个项目大约99%是使用Claude生成的（“vibe编码”）。这是一项正在进行的工作——贡献和 错误报告 欢迎光临！

这是什么？

这款应用程序让像克劳德这样的人工智能助手通过自然语言控制你的Hubitat智能家居。只需与它对话：

“打开客厅的灯”

“卧室里的温度是多少？”

“制定一条午夜关灯的规则”

“当检测到走廊有动静时，打开走廊灯5分钟”

“当温度保持在78以上5分钟时，打开空调”

“日落时打开户外灯”

当卧室按钮被双击时，切换卧室灯

“该中心的健康状况如何？”

在幕后，人工智能使用MCP工具来控制设备、创建自动化规则、管理房间、查询系统状态和管理中心。服务器总共公开了103个工具——23个核心工具始终可见，而另外80个工具则组织在13个域名网关后面，以保持工具列表的可管理性。如果您的客户端能够很好地处理长工具列表，您可以通过以下方式禁用网关 整合类别网关背后的工具 设置，每个工具都单独暴露。（此处的计数描述了已发货的目录；运行时计数基于 tools/list 根据启用的设置而有所不同。)

需求

• Hubitat Elevation C-7、C-8或C-8 Pro
• Hubitat固件2.3.0+（用于OAuth和内部API支持）

安装

选项A:Hubitat软件包管理器（推荐）

如果您尚未安装Hubitat软件包管理器（HPM），请按照以下步骤操作 HPM安装说明 首先进行设置。

安装HPM后：

1. 打开HPM> 安装
2. 搜索 “MCP”
3. 选择 MCP规则服务器 并安装

就是这样！HPM将自动安装父应用程序和子应用程序，并在更新可用时通知您。

HPM替代方法：您也可以使用HPM> 安装 > 从URL 并粘贴： `` https://raw.githubusercontent.com/kingpanther13/Hubitat-local-MCP-server/main/packageManifest.json ``

选项B：手动安装

您需要安装 二 应用程序文件：

1.安装父应用程序（MCP规则服务器）：

1. 转到Hubitat web UI> 应用程序代码 > +新应用程序
2. 点击 导入 并粘贴此URL：

   https://raw.githubusercontent.com/kingpanther13/Hubitat-local-MCP-server/main/hubitat-mcp-server.groovy

1. 点击 导入 > 好的 > 保存
2. 点击 OAuth > 在应用程序中启用OAuth > 保存

2.安装子应用程序（MCP规则）：

1. 首选 应用程序代码 > +新应用程序
2. 点击 导入 并粘贴此URL：

   https://raw.githubusercontent.com/kingpanther13/Hubitat-local-MCP-server/main/hubitat-mcp-rule.groovy

1. 点击 导入 > 好的 > 保存
2. （子应用程序不需要OAuth）

快速开始

1.添加应用程序

1. 首选 应用 > +添加用户应用程序 > MCP规则服务器
2. 选择您希望通过MCP访问的设备
3. 点击 完成
4. 打开应用程序查看端点URL并管理规则

2.获取您的端点URL

该应用程序显示两个端点URL：

• 本地端点 --在本地网络上使用：

  http://192.168.1.100/apps/api/123/mcp?access_token=YOUR_TOKEN

• 云端点 --对于远程访问（需要Hubitat Cloud订阅）：

  https://cloud.hubitat.com/api/YOUR_HUB_ID/apps/123/mcp?access_token=YOUR_TOKEN

3.连接您的AI客户端

运输：此服务器使用 流式HTTP （不是SSE或stdio）。您的MCP客户端必须支持HTTP传输——默认情况下大多数都支持。

Claude Code (CLI)

添加到MCP设置文件(~/.claude.json 或项目 .mcp.json):

{
  "mcpServers": {
    "hubitat": {
      "type": "url",
      "url": "http://192.168.1.100/apps/api/123/mcp?access_token=YOUR_TOKEN"
    }
  }
}

对于远程访问，请使用Hubitat Cloud URL。

或者，有些人很幸运，只是简单地让Claude访问自己的目录，给它URL并要求它建立自己的连接。

Claude Desktop

添加到您的Claude Desktop配置文件中：

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• 视窗: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "hubitat": {
      "type": "url",
      "url": "http://YOUR_HUB_IP/apps/api/123/mcp?access_token=YOUR_TOKEN"
    }
  }
}

或者，有些人很幸运，只是简单地让Claude访问自己的目录，给它URL并要求它建立自己的连接。

Claude.ai (Connectors)

Claude.ai通过以下方式支持MCP服务器 连接器:

1. 首选 claude.ai > 设置 > 连接器
2. 使用Hubitat端点URL添加新连接器
3. 使用 云端点 远程访问的URL，或使用Cloudflare隧道URL

借助Hubitat Cloud，您可以在任何地方通过claude.ai控制您的智能家居，无需本地设置！

备注：在claude.ai上连接时，您将看到一条消息，指出“无法访问MCP服务器。您可以检查服务器URL并验证服务器是否正在运行。如果这种情况持续存在，请与支持人员共享此参考：”ofid_1234“”。

这是Claude.ai的UI的一个已知错误。看到此消息后，单击“配置”，您将发现您实际上已连接。试着让克劳德在聊天中检查你的Hubitat的健康状况，你会看到它发挥了神奇的作用！

Other AI Services

任何通过HTTP URL支持MCP服务器的AI服务都可以使用此服务器。使用以下任一方法：

• 云端 URL --Hubitat Cloud订阅无需额外设置
• Cloudflare隧道 --有关免费的自托管远程访问（请参阅 远程访问)

Claude.ai的代理技能（可选）

一 代理技能 是一个知识包，教Claude使用此MCP服务器的最佳实践——设备安全协议、规则创建模式、工具使用技巧等等。这不是必需的（Claude没有它也能很好地工作），但它可以帮助Claude做出更好的决策，特别是在设备授权和中心管理工具等安全关键操作方面。

要安装：

1. 下载 agent-skill/hubitat-mcp/ 此存储库中的文件夹
2. 压缩它，使文件夹成为根目录： hubitat-mcp.zip > hubitat-mcp/ > SKILL.md等等。
3. 首选 claude.ai > 设置 > 特性 > 技能
4. 上传zip文件

该技能与MCP连接器一起工作——连接器为克劳德提供了工具，该技能教会克劳德如何很好地使用它们。

适用于Claude Code用户：您还可以将技能文件夹复制到 ~/.claude/skills/hubitat-mcp/ 用于自动装载。

远程访问选项

Option 1: Hubitat Cloud (Easiest)

如果你有 云 Hubitat 订阅：

1. 云端点URL直接显示在应用程序中
2. 在MCP客户端配置中使用该URL
3. 无需额外设置！

Option 2: Cloudflare Tunnel (Free, Self-Hosted)

无需Hubitat Cloud订阅即可免费远程访问：

1. 安装 云层爆发
2. 创建隧道：

   # cloudflared config.yml
   ingress:
     - hostname: hubitat-mcp.yourdomain.com
       service: http://YOUR_HUB_IP:80
     - service: http_status:404

1. 使用您的隧道URL：

   https://hubitat-mcp.yourdomain.com/apps/api/123/mcp?access_token=YOUR_TOKEN

______________________________________________________________________

特性

MCP工具（共103个——工具/清单上有36个）

服务器总共有103个工具。保留MCP tools/list 可管理的， 23个核心工具 始终可见，并且 80个附加工具 组织在后面 13个域名网关AI在上看到36个项目 tools/list （23+13个网关）。每个网关的描述都包括工具摘要（AI始终可见），调用没有参数的网关会按需返回完整的参数模式。

核心工具（23）——在工具/列表上始终可见

Devices (6) — Control and query devices

Rules (4) — Create and manage automation rules

Device Management (1)

System (5) — Hub modes, HSM, and info

Virtual Devices (2) — MCP-managed virtual devices

Hub Utilities (3) — Backup, updates, and diagnostics

Reference (2)

网关工具（13）——每个网关代理多个工具

调用不带参数的网关以查看完整的参数模式。来电 tool='' 和 args={...} 执行特定工具。

manage_rules_admin (5) — Rule administration

manage_hub_variables (8) — Hub variables

manage_rooms (5) — Room management

manage_destructive_hub_ops (3) — Destructive hub operations

所有操作都是破坏性的。集线器管理工具要求在设置中启用集线器管理读/写。编写工具强制执行 三层安全门：启用集线器管理员写入+在24小时内进行集线器备份+显式 confirm=true.

manage_apps_drivers (7) — App/driver/library listing, source code, and backups (read-only)

manage_app_driver_code (10) — Install, update, delete apps/drivers/libraries and restore backups

在执行任何修改/删除操作之前，源代码都会自动备份。

manage_logs (8) — Logs, performance stats, and log configuration

监控工具需要启用集线器管理读取。

manage_diagnostics (11) — Diagnostics, memory, radio details, and state capture

manage_files (4) — Hub File Manager

写入/删除需要集线器管理员写入+确认。

manage_installed_apps (4) — Built-in app visibility and configuration

list_installed_apps 和 get_device_in_use_by 要求选择加入 启用内置应用程序工具 设置。 get_app_config 和 list_app_pages 需要集线器管理员读取。

manage_hpm (2) — Hubitat Package Manager state introspection (read-only)

这两个工具都需要集线器管理员读取。HPM本身必须安装在轮毂上。

manage_native_rules_and_apps (12) — Rule Machine interop (RMUtils) + native CRUD on any classic SmartApp (RM, Room Lighting, Button Controllers, Basic Rules, Notifier, etc.)

需要选择加入 启用内置应用程序工具 设置。创建/更新/删除还需要集线器管理员写入。

manage_mcp_self (1) — Developer Mode self-administration

下的第一个网关 开发者模式 模式——用于需要管理MCP规则应用程序自己的配置而无需手动UI干预的LLM代理和CI/CD管道。其他自我管理工具（设备访问管理、真正的Hub Variables命名空间支持、工件清理）计划作为同一切换下的后续工具。需要选择加入 启用开发人员模式工具 设置（默认关闭）。每次成功写入都会以警告级别记录以供审核。

规则引擎

通过自然语言创建自动化——人工智能将您的请求转换为带有触发器、条件和动作的规则。您还可以通过Hubitat web UI管理规则。

Supported Triggers (6 types)

Supported Conditions (14 types)

Supported Actions (29 types)

Rule Examples

运动激活灯：

{
  "name": "Motion Light",
  "triggers": [
    { "type": "device_event", "deviceId": "123", "attribute": "motion", "value": "active" }
  ],
  "conditions": [
    { "type": "time_range", "startTime": "sunset", "endTime": "sunrise" }
  ],
  "actions": [
    { "type": "device_command", "deviceId": "456", "command": "on" },
    { "type": "delay", "seconds": 300, "delayId": "motion-off" },
    { "type": "device_command", "deviceId": "456", "command": "off" }
  ]
}

去抖动温度：

{
  "name": "AC On When Hot",
  "triggers": [
    { "type": "device_event", "deviceId": "1", "attribute": "temperature",
      "operator": ">", "value": "78", "duration": 300 }
  ],
  "actions": [
    { "type": "device_command", "deviceId": "8", "command": "on" }
  ]
}

带有局部变量的按钮状态机：

{
  "name": "Smart Button Toggle",
  "localVariables": { "lastScene": "natural" },
  "triggers": [
    { "type": "button_event", "deviceId": "80", "action": "pushed" }
  ],
  "actions": [
    {
      "type": "if_then_else",
      "condition": { "type": "variable", "variableName": "lastScene",
                     "operator": "equals", "value": "natural" },
      "thenActions": [
        { "type": "activate_scene", "sceneDeviceId": "nightlight-scene" },
        { "type": "set_local_variable", "variableName": "lastScene", "value": "nightlight" }
      ],
      "elseActions": [
        { "type": "activate_scene", "sceneDeviceId": "natural-scene" },
        { "type": "set_local_variable", "variableName": "lastScene", "value": "natural" }
      ]
    }
  ]
}

______________________________________________________________________

中心管理工具

集线器管理员读取和集线器管理员写入访问权限都是 默认情况下禁用 并且必须在应用程序设置中明确启用。

Enabling Hub Admin Tools

1. 打开 应用 > MCP规则服务器 在Hubitat网络用户界面中
2. 在...之下 集线器管理员访问，切换：

- 启用集线器管理员读取工具 --用于只读中心信息 - 启用集线器管理员写入工具 --用于备份、重启、关机、Z-Wave修复和应用程序/驱动程序管理

1. 如果你的中心有 集线器安全 启用，还配置：

- 集线器安全用户名 和 密码 在集线器安全部分下

Safety Gates

所有Hub Admin Write工具都强制执行 三层安全门:

1. 集线器管理员写入必须为 启用 在设置中
2. AI必须通过 confirm=true 明确地
3. 一个完整的枢纽 备份必须在过去24小时内存在 （自动执行）

此外，修改或删除现有应用程序/驱动程序的工具在进行更改之前会自动备份项目的源代码。

Item Backup & Restore

当你使用 update_app_code, update_driver_code, delete_app，或 delete_driver，服务器自动保存 原始源代码 在做出改变之前。

• 备份存储为 .groovy 集线器本地中的文件 文件管理器
• 命名 mcp-backup-app-.groovy 或 mcp-backup-driver-.groovy
• 即使卸载了MCP应用程序，也会持续存在
• 可在以下网址下载 http:///local/
• 最多保留20个；最老的自动修剪
• 1小时保护窗口：多次编辑保留编辑前的原始内容

通过MCP恢复：

1. list_item_backups 查看可用备份
2. restore_item_backup 使用备份密钥和 confirm=true

手动还原（无MCP）：

1. 转到Hubitat web UI> 设置 > 文件管理器
2. 下载备份文件（例如。， mcp-backup-app-123.groovy)
3. 首选 应用程序代码 （或 驾驶员代码)>选择应用程序>粘贴源> 保存

Hub Security Support

如果您的集线器启用了集线器安全（web UI需要登录），MCP服务器将自动处理身份验证：

• 在应用程序设置中配置您的Hub Security用户名和密码
• 服务器将会话cookie缓存30分钟
• 过期的Cookie会自动清除并重新验证
• 如果未启用集线器安全，则不需要凭据

______________________________________________________________________

性能和限制

Hub Hardware Recommendations

Known Limits

• list_devices 随着 detailed=true --在50多台设备上可能会很慢。使用分页： list_devices(detailed=true, limit=25, offset=0).使用 labelFilter 或 capabilityFilter 在分页之前缩小服务器端。使用 fields=[...] 跳过昂贵的集线器读取-- currentStates 和 attributes 每个设备集线器的触发器读取，是值得突出的； capabilities 和 commands 它们在内存中，而且很便宜。
• 持续时间触发器 --最多2小时（7200秒）
• 被占领的州 --默认限制为20（设置中可配置1-100）
• Hubitat 云 响应 --最大128KB（AWS MQTT限制）。对大型设备列表使用分页。
• 无实时事件流（仅MCP响应）
• 日出/日落时间每天重新计算

______________________________________________________________________

故障排除

Device not found

确保在应用程序的“选择MCP访问设备”设置中选择了该设备。

OAuth token not working

1. 打开应用程序代码>MCP规则服务器
2. 单击OAuth>在应用程序中启用OAuth
3. 保存
4. 在Apps中重新打开应用程序以获取新令牌

Rules not triggering

• 检查“启用规则引擎”是否处于应用内设置中
• 启用“调试日志”并检查Hubitat日志
• 验证触发设备是否已选择用于MCP访问
• 对于基于持续时间的触发器，确保条件在整个持续时间内保持不变

Button events not working

• 确保您正在使用 button_event 触发器类型（非 device_event)
• 验证按钮动作类型： pushed, held, doubleTapped，或 released

list_devices(detailed=true) fails over Hubitat Cloud

Hubitat Cloud 的 128KB响应大小限制 （AWS MQTT限制）。使用分页和服务器端过滤来保持在限制范围内：

list_devices(detailed=true, limit=25, offset=0)               // First 25 devices
list_devices(detailed=true, limit=25, offset=25)              // Next 25 devices
list_devices(capabilityFilter='Switch', limit=25, offset=0)   // Only Switch devices
list_devices(fields=['id','label','currentStates'], limit=50) // Slim payload

回应包括 total, hasMore，以及 nextOffset 以帮助分页。

Rules from v0.0.x not showing

版本0.1.0使用了新的父/子架构。旧规则存储在 state.rules 不会自动迁移。您需要通过UI或MCP重新创建规则。

Reporting bugs

为了更容易报告错误：

1. 设置调试日志级别：设置>MCP调试日志级别>“调试”，或要求您的AI set_log_level “调试”
2. 重现该问题
3. 让你的AI使用 generate_bug_report 工具——它将收集诊断信息并格式化一份准备提交的报告
4. 提交至

______________________________________________________________________

Future Plans

蓝天创意 --下面的一切都是推测性的，需要进一步研究以确定可行性。这些功能都没有得到保证或承诺。 状态键： [ ] =未启动| [~] =进行中/部分完成| [x] =已完成| [?] =需要研究/可行性未知 可行性研究于2025年2月进行。 每个项目现在都包括一个难度等级（1-5）、工作量估算和基于全面代码库分析的实现说明。 难度键： 1 =微不足道| 2 =直截了当| 3 =中等| 4 =复杂| 5 =极其复杂 努力关键： S =小（小时）| M =中等（1-3天）| L =大型（4+天）

______________________________________________________________________

规则引擎增强功能

触发器增强功能

• \[x\] 条件触发器（在触发时评估） — Difficulty: 1 | Effort: S

> *已经实施。* 这 evaluateTriggerCondition() 方法计算每个触发器的值 condition 现场使用全条件系统。每个触发器处理程序都已经调用了这个。可以从更好的文档和MCP工具模式更新中受益，使该功能更容易被发现。

• \[x\] Cron/周期性触发器 — Difficulty: 1 | Effort: S

> *已经实施。* 这 periodic 触发器类型通过以下方式在内部生成cron表达式 schedule()。要公开原始cron支持，请添加 cron 直接传递用户提供的cron表达式的子类型。Hubitat接受标准的7字段cron表达式。用户提供的字符串需要验证。

• \[ \] 端点/webhook触发器 — Difficulty: 3 | Effort: M

> *可行。* 添加单个调度器端点（例如。， /mcp/webhook?ruleKey=)在父应用程序中 mappings 块。父级按键查找子级规则并调用 executeRule("webhook", webhookEvt) 其中请求体/params作为事件数据。按照规则动态路径是不可能的，因为 mappings 是编译时，但具有查询参数的共享端点是有效的。OAuth访问令牌已经保护了路径。 > > 实施计划： > > 1. 添加 GET/POST /webhook 映射到父应用程序 > 1. 添加 webhook 将触发器类型设置为子应用程序的 subscribeToTriggers() > 1. 父级通过键查找分派到匹配的子级规则 > 1. 将请求正文、标头和查询参数打包到伪事件中，以进行变量替换

• \[x\] 集线器变量更改触发 — *关闭方式与原计划不同（第92期）。*

> 最初范围为 variable_change 传统MCP规则引擎的触发器类型。随着传统引擎现在冻结，原生规则机原生提供可变触发器，MCP/AI消费者的等效功能作为观察工具提供：父应用程序订阅 variable:* 安装/更新时的位置事件，缓冲最近200次更改 atomicState.variableHistory，并通过以下方式暴露它们 get_variable_historyThe renameVariable(oldName, newName) 回调使缓冲区在UI重命名过程中保持一致。见PR关闭#92/#96。

• \[ \] 系统启动触发器 — Difficulty: 2 | Effort: S

> *可行。* Hubitat支持 subscribe(location, "systemStart", handler).添加a system_start 触发器类型。集线器重启后，应用程序恢复， initialize() → subscribeToTriggers() 运行，systemStart事件触发规则。轻微边缘情况：事件可能会在所有应用程序完成还原之前触发——需要在硬件上进行测试。 > > 实施计划： > > 1. 添加 system_start 触发器类型到子应用程序 > 1. 订阅 location "systemStart" 事件输入 subscribeToTriggers() > 1. 处理程序调用 executeRule("system_start")

• \[ \] 日期范围触发器 — Difficulty: 2 | Effort: S

> *可行。* 作为条件而不是触发器更好地实施。A. date_range 条件类型检查 new Date() 根据开始/结束日期，遵循与以下相同的模式 time_range 和 days_of_week。如果作为触发器实现，请使用 schedule() 从靶场开始射击。 java.util.Calendar 在沙盒中可用。 > > 实施计划： > > 1. 添加 date_range 条件类型为 evaluateCondition() > 1. 接受 startDate 和 endDate （ISO格式） > 1. 可选择添加 date_range 触发器，在范围开始时安排一次性事件

条件增强

• \[ \] 带飞行中动作取消的必需表达式（规则门） — Difficulty: 4 | Effort: L

> *可行但复杂。* “门”是在动作执行过程中持续监控的状态。如果它变为false，则取消飞行中的延迟操作。现有的 cancelledDelayIds 该机制为取消提供了基础。大门需要自己的 subscribe() 调用相关设备，并使用一个处理程序检查门状态并将所有挂起的延迟ID标记为已取消。这是架构上最复杂的增强功能——它需要在延迟操作链期间进行异步监控和仔细的状态管理。 > > 实施计划： > > 1. 添加 requiredExpressions 数组到规则结构旁边 conditions > 1. 单独订阅闸门相关设备事件 > 1. 门处理程序评估条件，如果为false，则取消所有活动延迟 > 1. 按照规则跟踪所有活动延迟ID atomicState.activeDelayIds > 1. 在规则执行正常完成时添加清理逻辑

• \[ \] 全布尔表达式生成器（带嵌套的AND/OR/XOR/NOT） — Difficulty: 4 | Effort: L

> *可行。* 更换扁平条件阵列+ conditionLogic 使用递归树结构切换： {operator: "AND", operands: [...]}.重写 evaluateConditions() 作为一名树行者。不包装单个操作数；XOR只检查一个true。现有的 evaluateCondition() 因为叶子节点已经是模块化的。主要的挑战是MCP工具的人机工程学和向后兼容性——平面阵列格式需要迁移逻辑。 > > 实施计划： > > 1. 定义树数据结构 operator 和 operands 领域 > 1. 实现递归 evaluateConditionTree() 方法 > 1. 支持传统平面格式和新树格式（迁移路径） > 1. 更新 custom_create_rule/custom_update_rule 工具模式 > 1. 更新 describeCondition() 用于递归格式化

• \[ \] 每个规则的私有布尔值 — Difficulty: 2 | Effort: S

> *可行。* 已经可以通过以下方式实现 atomicState.localVariables.添加专用 set_rule_boolean 调用的动作类型 parent.setRuleBooleanOnChild(targetRuleId, boolName, value)，它更新目标孩子的局部变量。添加一个 rule_boolean 读取特定规则局部变量的条件类型。家长通过以下方式调解跨规则访问 getChildAppById(). > > 实施计划： > > 1. 添加 set_rule_boolean 动作类型到子应用程序 > 1. 添加 rule_boolean 条件类型为 evaluateCondition() > 1. 添加 setRuleBooleanOnChild() 父应用程序的方法 > 1. 更新MCP工具模式

动作增强

• \[ \] 随着时间的推移逐渐变暗 — Difficulty: 3 | Effort: M

> *可行。* 许多调光器本机支持 setLevel(level, duration) 代码库已经在使用它。对于软件淡入淡出：计算步长和间隔，然后使用 runIn() 循序渐进。示例：0→100 60秒以上=每3秒5%（20步）。将步数限制在20到30之间，以避免压倒集线器的调度器。与色温渐变和渐变操作共享步进实用程序。 > > 实施计划： > > 1. 添加 fade_dimmer 动作类型 startLevel, endLevel, durationSeconds > 1. 实施 rampValue() 阶梯式实用工具 runIn() 调度 > 1. 使用 [overwrite: false] 上 runIn() 用于非冲突回调 > 1. 回归本土 setLevel(level, duration) 当设备支持它时

• \[ \] 随时间改变色温 — Difficulty: 3 | Effort: M

> *可行。* 与渐变调光器相同的图案。使用共享 rampValue() 实用程序与 setColorTemperature() 呼叫每一步。某些设备支持 setColorTemperature(temp, level, duration) 本地。温度范围因设备而异（通常为2000K-6500K）。 > > 实施计划： > > 1. 添加 fade_color_temperature 动作类型 startTemp, endTemp, durationSeconds > 1. 重复使用 rampValue() 渐变调光器的实用程序 > 1. 处理温度步长的整数舍入

• \[ \] 按模式操作 — Difficulty: 2 | Effort: S

> *可行。* 添加一个 per_mode 动作类型，包含模式名称到动作列表的映射。执行时，检查 location.mode 并执行匹配的动作列表。结构上类似于 if_then_else 但有多个分支。现有的 if_then_else 带着一个 mode 这种条件已经不那么符合人体工程学地提供了这种能力。 > > 实施计划： > > 1. 添加 per_mode 动作类型 modeActions 地图 > 1. 查找 location.mode 执行时 > 1. 使用现有操作列表执行匹配操作列表 executeAction() 基础设施

• \[ \] 等待事件/等待表达式 — Difficulty: 5 | Effort: L

> *部分可行。* 需要在执行过程中暂停，直到发生外部事件。在Hubitat的单线程模型中，没有阻塞等待。实现：将当前执行状态（动作索引、上下文）保存到 atomicState，订阅目标事件，从执行中返回，然后在事件触发时继续——类似于 delay 模式，但事件触发。强制超时是必不可少的。等待订阅和其他触发器之间可能存在竞争条件。 > > 实施计划： > > 1. 添加 wait_for_event 带有目标设备/属性和强制超时的操作类型 > 1. 将执行状态保存到 atomicState （图案与 delay) > 1. 为目标事件创建临时订阅 > 1. 在事件触发或超时时，从保存状态恢复执行 > 1. 恢复后清理订阅

• \[ \] 重复，直到 — Difficulty: 4 | Effort: L

> *部分可行。* 扩展现有 repeat 在每次迭代之前/之后评估条件的动作。关键安全：100次迭代的硬上限（匹配现有 repeat cap）、强制最大迭代参数和环路保护。如果循环体包含延迟，则每次迭代都需要保存状态/恢复模式，这使得实现变得极其复杂。建议最初仅支持同步循环（主体中没有延迟）。 > > 实施计划： > > 1. 添加 repeat_while 和 repeat_until 操作类型 > 1. 通过以下方式评估情况 evaluateCondition() 每次迭代 > 1. 强制执行 maxIterations 上限（≤100） > 1. 阶段1：仅同步循环（体内无延迟动作） > 1. 阶段2（未来）：具有状态持久性的延迟兼容循环

• \[ \] 规则到规则控制 — Difficulty: 2 | Effort: M

> *可行。* 添加 enable_rule, disable_rule，以及 trigger_rule 动作类型。子节点调用父节点，父节点查找目标子节点并调用现有子节点 enableRule()/disableRule()/executeRule()。为了防止跨规则乒乓球循环，请传递一个“触发链深度”计数器，并拒绝深度超过5的执行。 > > 实施计划： > > 1. 添加 enable_rule, disable_rule, trigger_rule 操作类型 > 1. 实施 triggerChildRule(targetRuleId, depth) 在父母 > 1. 添加深度计数器 executeRule() 防止级联循环 > 1. 通过验证目标规则是否存在 getChildAppById()

• \[ \] 文件写入/追加/删除 — Difficulty: 2 | Effort: S

> *可行。* 家长已经 uploadHubFile()/downloadHubFile() 包装纸。新动作类型 file_write, file_append, file_delete 调用父方法。Append执行读-修改-写循环（非原子）。需要集线器管理员写入门。内容中的变量替换启用了动态日志文件。 > > 实施计划： > > 1. 添加 file_write, file_append, file_delete 操作类型 > 1. 孩子的呼唤 parent.writeFileFromRule(fileName, content, mode) > 1. 根据验证文件名 [A-Za-z0-9._-] 模式 > 1. 应用Hub管理员写入安全门

• \[ \] 音乐/警报器控制 — Difficulty: 2 | Effort: S

> *可行。* 现有便利包装 device_commandHubitat 你 capability.musicPlayer （播放、暂停、停止、设置音量、播放曲目）和 capability.alarm （警报器、闪光灯、关闭）。现有的 speak 该动作演示了TTS的音量模式。这些将是符合人体工程学的动作类型，具有内置的正确功能验证。 > > 实施计划： > > 1. 添加 play_music 动作类型，包括设备、命令、音量、轨迹参数 > 1. 添加 activate_siren 带装置的动作类型，模式（警报器/闪光灯/两者/关闭） > 1. 在执行之前验证设备是否具有所需的功能

• \[x\] 自定义操作（任何功能+命令） — Difficulty: 1 | Effort: S

> *已经实施。* 现有的 device_command 操作类型通过动态调用接受任何设备ID、命令和参数(device."${command}"(*params)).这是“任何能力+命令”功能。

• \[ \] 禁用/启用设备 — Difficulty: 1 | Effort: S

> *可行（部分完成）。* 这 update_device MCP工具已经支持 enabled 财产通过内部 /device/disable 终点。新的 set_device_enabled 规则操作类型封装了相同的调用。需要集线器管理员写入。如果目标设备在活动规则触发器中使用，应发出警告。 > > 实施计划： > > 1. 添加 set_device_enabled 动作类型 deviceId 和 enabled 布尔 > 1. 呼叫 parent.setDeviceEnabled(deviceId, enabled) > 1. 检查设备是否用于任何规则触发和警告

• \[ \] 斜坡动作（连续上升/下降） — Difficulty: 3 | Effort: M

> *部分可行。* 与渐变调光器/色温相同的软件步进模式。通用 ramp 动作针对任何数字属性。真正的连续升高/降低（如按住物理调光器按钮）使用 startLevelChange(direction) / stopLevelChange() 但不能受软件的时间限制。分享 rampValue() 带有淡入淡出动作的实用程序。 > > 实施计划： > > 1. 添加 ramp 动作类型，包括设备、属性、开始、结束、持续时间、步骤 > 1. 重用 rampValue() 淡入淡出操作的实用程序 > 1. 对于具有以下功能的设备 startLevelChange/stopLevelChange，提供硬件斜坡选项

• \[x\] Ping IP地址（ICMP） --折叠成 device_health_check （第91期）。

> 而不是独立的 ping_host ICMP ping已集成到现有的工具中 device_health_check 工具via pingHosts （最多5个IPv4）和 pingCount （1–5）参数。每个主机都被ping通 hubitat.helper.NetworkUtils.ping() 并报告如下 pingResults 随着 reachable, rttAvg, rttMin, rttMax, packetsTransmitted, packetsReceived, packetLoss自定义MCP规则引擎仅为传统版本，因此未添加规则操作的一半。

• \[ \] HTTP可达性检查 — Difficulty: 3 | Effort: M

> *可行——补充上述ICMP ping。* 对目标URL的HTTP GET仍然对不响应ICMP的主机有价值，或者当您需要验证HTTP层健康状况时，而不仅仅是网络可达性。与本机ping一起作为辅助操作类型保留。 > > 订购须知。 asynchttpGet() 非阻塞：之后的任何操作 http_check 否则，规则的操作列表将在响应到达之前和结果变量之前运行(reachable, statusCode, responseTimeMs)人口稠密。正确的实现必须在调度时保存规则执行状态，并从异步回调中恢复——与现有的保存状态/恢复模式相同 delay 行动。需要强制超时，这样挂起的请求就不会使规则挂起。 > > 实施计划： > > 1. 添加 http_check 带有目标URL、可选预期状态代码和强制超时的操作类型 > 1. 通过以下方式发送 asynchttpGet() （非阻塞，不捆绑轮毂执行器） > 1. 将动作索引+上下文保存到 atomicState 在调度之前，镜像 delay 动作的恢复模式 > 1. 在异步回调中，填充结果字段(reachable, statusCode, responseTimeMs)进入规则/局部变量，并从保存的索引中恢复操作执行 > 1. 强制执行硬超时，然后恢复 reachable=false 如果没有及时响应 > 1. 同步 httpGet() 这不是一个可接受的快捷方式——它会阻止中心事件执行器，并可能使其他应用程序停滞

系统

• \[ \] 集线器可变连接器（作为设备属性公开） — Difficulty: 4 | Effort: L

> *部分可行。* Hubitat的内置变量连接器功能（固件≥2.3.4）已经可以处理集线器变量。对于MCP规则引擎变量，将其作为设备属性公开需要：（1）自定义虚拟设备驱动程序，（2）父级通过以下方式创建实例 addChildDevice()（3）父级通过以下方式更新属性 sendEvent() 关于变量写入。自定义驱动程序向项目添加了第三个文件，并增加了安装复杂性。 > > 实施计划： > > 1. 创建 MCP Variable Connector 驱动程序（新Groovy文件） > 1. 父设备在第一次写入变量时（或按需）自动创建子设备 > 1. 扩展 setRuleVariable() 也 sendEvent() 在连接器设备上 > 1. 将驱动程序添加到HPM包清单 > 1. 记录集线器变量应使用Hubitat的内置连接器

• \[~\] 可变变更事件 — *轮毂变量在问题#92下半关闭；MCP规则引擎半延迟（旧引擎冻结）。*

> 中心变量变化观测现在通过以下方式发送 get_variable_history （见上文“集线器变量更改触发器”）。MCP规则引擎的一半——发送 ruleVariableChanged 位置事件 setRuleVariable() 写入-将需要在不再扩展的遗留子应用程序中添加新代码。新的规则变量消费者应该使用内置变量触发器的本机规则机。

• \[ \] 局部变量触发 — Difficulty: 2 | Effort: S

> *可行。* 之后 set_local_variable 或 variable_math 修改局部变量，检查是否匹配 local_variable_change 通过异步方式触发和重新触发 runIn(0, handler).如果规则触发自身，则存在无限循环的高风险——建议仅从外部更改触发（另一个规则通过规则到规则控制设置此规则的局部变量）。护圈提供了一个安全网。 > > 实施计划： > > 1. 添加 local_variable_change 触发类型 > 1. 局部变量修改后，安排异步重新评估 > 1. 添加 triggerSource 跟踪以防止自触发循环 > 1. 依靠环护作为安全网

______________________________________________________________________

内置自动化等效物

哲学：更喜欢本土Hubitat应用程序。 MCP服务器是为了补充Hubitat而不是取代它而构建的。这些本地应用程序（房间照明、模式管理器、按钮控制器等）维护良好，具有适当的UI，并且经过了战斗测试。MCP已经可以与 *效果* 在这些应用程序中，它可以读取/设置模式、控制设备、触发设备事件，并查看它们创建的虚拟设备。 AI助手就是巫师。 与其构建生成MCP规则的专用向导工具来复制本地应用程序已经做的事情，人工智能可以使用现有的即时编写规则 custom_create_rule 以及完整的规则引擎。这些图案的专用MCP工具是 低优先级 并且只有在MCP确实无法以某种方式与本地应用程序的功能交互的情况下才会实现。每个项目都将根据具体情况进行审查。

• \[ \] 房间照明（以房间为中心的照明，带空置模式） — Low priority

> *首选本地应用程序。* Hubitat的内置房间照明应用程序很好地处理了这一点。MCP已经可以控制所有相同的设备，触发运动事件，并使用 if_then_else / delay / cancel_delayed 通过以下方式构建等效逻辑 custom_create_rule 如果需要的话。除非发现MCP无法与房间照明行为交互的间隙，否则不需要专用的MCP工具。

• \[ \] 区域运动控制器（多传感器区域） — Low priority

> *首选本地应用程序。* Hubitat的内置区域运动控制器创建了一个聚合多个传感器的虚拟运动设备。如果用户将此虚拟设备添加到MCP的选定设备中，MCP已经可以看到并触发它。AI还可以使用 create_virtual_device + custom_create_rule 如果需要，可以使用多设备触发器。仅当MCP无法与本机应用程序的输出设备充分交互时才执行。

• \[ \] 模式管理器（自动模式更改） — Low priority

> *首选本地应用程序。* Hubitat的内置模式管理器可处理基于时间和基于状态的模式更改。MCP已经可以通过以下方式读取/设置模式 get_modes/set_mode，触发器打开 mode_change，并构建调用的时间/在场触发规则 set_mode除非发现特定的交互间隙，否则不需要专用工具。

• \[ \] 按钮控制器（流线型按钮到动作映射） — Low priority

> *首选本地应用程序。* Hubitat的内置按钮控制器本机处理此问题。MCP规则引擎已经具有 button_event 触发器完全支持按钮编号（1-20）和动作类型（按下/按住/双击/释放）。人工智能可以直接通过以下方式创建这些规则 custom_create_rule不需要专用工具。

• \[ \] 恒温器调度器（基于时间表的设定点） — Low priority

> *首选本地应用程序。* Hubitat内置的恒温器调度器处理基于时间表的设定点。MCP规则引擎已经具有 time 触发器， set_thermostat 行动， mode 和 days_of_week 条件——人工智能可以直接编写调度规则。除非MCP无法与本机调度器的效果交互，否则不需要专用工具。

• \[ \] 锁码管理器 — Low priority — review needed

> *可能需要专用工具。* Hubitat内置的锁定代码管理器通过UI处理代码管理。MCP已经可以通过以下方式发送锁定代码命令 send_command (setCode, deleteCode)并阅读 lockCodes/lastCodeName 属性，所以今天基本的交互是可能的。但是，本地应用程序的内部代码清单和临时代码调度不能直接访问。如果本机应用程序的输出不足，专用工具可能会为程序化代码管理增加价值。 需要逐案审查。

• ~~\[ \] 群组和场景（Zigbee群组消息）~~ — Not feasible

> *不可行。* 这 zigbee 对象和 sendHubCommand() 随着 Protocol.ZIGBEE 仅在驱动程序中可用，不在应用程序中可用。MCP服务器是一个应用程序，无法发送原始Zigbee命令或管理Zigbee组ID。Zigbee组管理由封闭源代码平台内部处理，没有记录的HTTP API端点。 > > 现有替代方案： > > - 利用内置的组和场景应用程序：引导用户通过内置应用程序创建Zigbee组，然后通过MCP控制生成的组激活器设备 send_command （组激活器设备是MCP已经可以控制的常规开关/调光器设备） > - 软件级组控制：创建顺序向多个设备发送命令的规则——已经可以通过多设备规则或 device_command 行动 > - 场景捕捉/恢复：现有 capture_state/restore_state 动作在多个设备上提供类似场景的功能

______________________________________________________________________

HPM和应用程序/集成管理

• \[ \] 按关键字搜索HPM存储库 — Difficulty: 2 | Effort: S

> *可行。* HPM使用的公共GraphQL API位于 https://hubitatpackagemanager.azurewebsites.net/graphqlA. search_hpm_packages 该工具通过以下方式发送GraphQL查询 httpPost() 并返回具有名称、描述、作者和清单URL的匹配包 https://raw.githubusercontent.com/HubitatCommunity/hubitat-packagerepositories/master/repositories.json 提供离线浏览。 > > 实施计划： > > 1. 创建 search_hpm_packages MCP工具 > 1. 发送GraphQL Search 查询Azure终结点 > 1. 对大型结果集进行分页分析并返回结果 > 1. 缓存结果 state 以减少API调用

• \[ \] 通过HPM安装/卸载软件包 — Difficulty: 4 | Effort: L

> *部分可行。* HPM没有可编程的API，它完全是由UI驱动的。 旁路方法：获取包清单JSON，下载每个应用程序/驱动程序源代码，并通过现有的 install_app/install_driver 工具。然而，以这种方式安装的软件包不会出现在HPM的“已安装”列表中，从而造成碎片化的体验。卸载需要通过文档记录不佳的方式删除正在运行的应用程序实例（而不仅仅是代码） /installedapp/ 端点。 > > 实施计划： > > 1. 创建 install_package 使用旁路方法的MCP工具 > 1. 获取清单→ 下载源→ 通过现有工具安装 > 1. 在文件管理器中跟踪已安装的软件包以进行更新检查 > 1. 记录限制：HPM不会知道这些安装 > 1. 要卸载： delete_app/delete_driver 对于代码，请进行调查 /installedapp/disable 例如

• \[ \] 检查已安装软件包的更新 — Difficulty: 3 | Effort: M

> *部分可行。* 对于MCP跟踪的包（来自上面的安装工具）：获取每个清单URL并比较版本——与现有模式相同 checkForUpdate() 对于MCP服务器本身。对于HPM管理的包：HPM的已安装包状态可通过集线器内部端点读取(/installedapp/statusJson/ + /hub2/appsList)，如所示 list_hpm_packages 和 get_hpm_driftA. check_package_updates 该工具可以将HPM记录的清单URL和版本与实时清单文件进行交叉引用，以检测可用的更新。 > > 实施计划： > > 1. 创建 check_package_updates MCP工具 > 1. 从文件管理器中读取MCP跟踪的包列表（适用于MCP安装的包） > 1. 对于HPM管理的软件包：使用 _hpmFetchManifests 获取记录的清单URL和版本；获取每个实时URL并比较版本字段 > 1. 返回包含可用更新的软件包列表 > 1. 优雅地处理获取失败（GitHub速率限制、网络问题）

• \[ \] 搜索尚未启用的官方集成 — Difficulty: 3 | Effort: M

> *部分可行。* 没有记录用于枚举可用内置应用程序的端点。这 list_hub_apps 该工具返回用户安装的应用程序类型，而不是内置类型。 实用方法：维护已知官方集成（Hue Bridge、Sonos、Alexa、Google Home、HomeKit等）的硬编码目录，并检查哪些集成有正在运行的实例。该列表仅随固件更新而更改。 > > 实施计划： > > 1. 创建 list_available_integrations MCP工具 > 1. 维护带有描述的官方集成硬编码目录 > 1. 检查已安装的应用程序实例，以确定哪些已启用 > 1. 返回可用但未启用与设置指南的集成 > 1. 使用每个MCP服务器版本更新目录

• \[ \] 从GitHub、论坛等发现社区应用程序/驱动程序。 — Difficulty: 3 | Effort: M

> *部分可行。* 主要机制：HPM存储库搜索（如上）。GitHub API搜索(https://api.github.com/search/repositories?q=hubitat+driver)可以工作，但未经验证的速率限制为10 req/min。Hubitat社区论坛没有搜索API。文件管理器中的策划列表是一个实用的后备方案。 > > 实施计划： > > 1. 创建 search_community_packages MCP工具 > 1. 主要：通过GraphQL搜索HPM存储库 > 1. 次要：可选的GitHub API搜索，带速率限制处理 > 1. 返回带有来源归因的组合结果 > 1. 在文件管理器中维护一个精选的热门软件包列表（可选）

______________________________________________________________________

仪表板管理

• \[ \] 以编程方式创建、修改、删除仪表板 — Difficulty: 4 | Effort: L

> *通过内部HTTP端点可行（需要经验测试）。* Hubitat的仪表板系统使用父子应用程序模式：“Hubitat仪表板”是父级，每个单独的仪表板都是一个子应用程序。深入的研究揭示了 /installedapp/createchild/ web UI使用的内部端点。 > > 主要发现： > > - 仪表板列表: GET /dashboard/all?pinToken= 或通过 GET /hub2/appsList 仪表板子项过滤 > - 仪表板创建: GET /installedapp/createchild/hubitat/Dashboard/parent/{dashboardParentAppId} --在父应用程序下创建一个新的子仪表板。返回重定向到 /installedapp/configure/{newChildId} > - 仪表板布局已读取: GET /apps/api/ /dashboard//layout?access_token= > - 仪表板布局编写: POST /apps/api/ /dashboard//layout 使用承载令牌身份验证 > - 仪表板删除：可能 POST /installedapp/configure/{childId} 采取删除行动，或 GET /installedapp/remove/{childId} （确切的终点需要测试） > - 儿童应用程序类型：命名空间 hubitat，姓名 Dashboard （从社区论坛的错误消息中确认） > > 重要注意事项： > > - addChildApp() 在Groovy中 不能 从MCP应用程序创建仪表板子项（父项不匹配），因此需要HTTP端点方法 > - 这 createchild 端点返回HTTP重定向（302），而不是JSON——需要从Location标头中提取新的子ID > - 创建后配置（仪表板名称、授权设备）需要单独的Post /installedapp/configure/{id} 带有表单编码数据 > - 仪表板父应用程序必须已安装在集线器上 > - 这 pinToken 为了 /dashboard/all 需要从仪表板父应用程序获取，或者本地API调用可能不需要 > - 固件≥2.3.9引入了“Easy Dashboard”作为替代方案——其内部结构可能有所不同 > - 所有端点都没有文档记录，并且可能会在固件版本之间发生变化 > > 实施计划： > > 1. 通过以下方式发现仪表板父应用ID GET /hub2/appsList （按应用程序名称筛选） > 1. 创建 create_dashboard 工具：调用 GET /installedapp/createchild/hubitat/Dashboard/parent/{parentId}，从重定向中提取新的子ID > 1. 配置新仪表板： POST /installedapp/configure/{newId} 带有名称和授权设备 > 1. 创建 list_dashboards 工具via /dashboard/all 或 /hub2/appsList > 1. 创建 get_dashboard_layout / update_dashboard_layout 布局JSON读/写工具 > 1. 创建 delete_dashboard 工具：测试 /installedapp/remove/{childId} 端点 > 1. 将仪表板父应用ID和访问令牌添加到MCP应用首选项中 > 1. 需要集线器管理员写入门以确保安全 > 1. 第一阶段：实现列表+读取/修改布局（已知工作端点） > 1. 第2阶段：实现创建/删除（需要对集线器硬件进行经验测试）

______________________________________________________________________

规则机器互操作性

可行性已确认 --无法创建/修改RM规则（闭源、无文档格式）。然而，通过以下方式控制现有的RM规则是可行的 hubitat.helper.RMUtils 类，可在Hubitat应用程序沙箱中使用。

• \[ \] 通过列出所有RM规则 RMUtils.getRuleList() — Difficulty: 1 | Effort: S

> *可行。* 确认工作。 RMUtils.getRuleList("5.0") 返回RM 5.x规则； getRuleList() 返回旧规则。返回一个适用于带有规则ID和名称的枚举选项的列表。 > > 实施计划： > > 1. 添加 import hubitat.helper.RMUtils 到父应用程序 > 1. 创建 list_rm_rules MCP工具 > 1. 两者都打电话 getRuleList("5.0") 和 getRuleList() 全面覆盖 > 1. 处理未安装RuleMachine的情况

• \[ \] 启用/禁用RM规则 — Difficulty: 2 | Effort: S

> *可行。* 用途 RMUtils.sendAction(ruleIds, "pauseRule"/"resumeRule", app.label, "5.0")“暂停”在RM术语中相当于“禁用”。 > > 实施计划： > > 1. 创建 control_rm_rule MCP工具 action 参数 > 1. 支持行动： pause （禁用）， resume （启用） > 1. 通过验证规则ID是否存在 getRuleList() 第一

• \[ \] 通过以下方式触发RM规则操作 RMUtils.sendAction() — Difficulty: 2 | Effort: S

> *可行。* 支持的操作： "runRuleAct" （执行动作、跳过条件）， "runRule" （评估条件，然后运行）， "stopRuleAct" （取消延迟/重复的操作）。注： "runRule" 不适用于规则4.x+。 > > 实施计划： > > 1. 添加 run_actions, evaluate, stop_actions 到 control_rm_rule 工具 > 1. 在内部映射到RM操作字符串 > 1. 记录哪些操作适用于哪些RM版本

• \[ \] 暂停/恢复RM规则 — Difficulty: 2 | Effort: S

> *可行。* 与上述启用/禁用机制相同。可以合并成统一 control_rm_rule 工具。

• \[ \] 设置RM专用布尔值 — Difficulty: 2 | Effort: S

> *可行。* 用途 RMUtils.sendAction(ruleIds, "setRuleBooleanTrue"/"setRuleBooleanFalse", app.label, "5.0").直截了当的API。 > > 实施计划： > > 1. 添加 set_boolean_true 和 set_boolean_false 到 control_rm_rule 工具 > 1. 接受规则ID和布尔值，映射到相应的sendAction调用

• \[x\] 用于跨发动机协调的轮毂可变桥 — Difficulty: 2 | Effort: S

> *已经实施了约90%。* 现有的 set_variable/get_variable 工具通过以下方式处理Hubitat的全局连接器变量 getGlobalConnectorVariable()/setGlobalConnectorVariable()这些是规则机读/写的相同变量。通过MCP设置的变量对RM立即可见，反之亦然。正式化：记录共享变量应使用集线器连接器变量的约定。

______________________________________________________________________

集成和流媒体

• \[ \] 事件流/webhooks（设备事件的实时POST） — Difficulty: 3 | Effort: M

> *可行。* 订阅设备事件和 asynchttpPost() 已注册URL的有效载荷。规则引擎已实现 http_request 行动通过 httpPost().使用 asynchttpPost （非阻塞）以避免在突发期间阻塞事件队列。利率限制很重要。 > > 实施计划： > > 1. 创建 configure_webhook 注册端点URL和事件过滤器的MCP工具 > 1. 将webhook配置存储在 state.webhookSubscriptions > 1. 在中订阅相关设备事件 initialize() > 1. 事件处理程序异步检查筛选器、格式化有效负载和POST > 1. 包括速率限制（每个webhook每分钟可配置的事件数） > 1. 有效载荷格式： {deviceId, label, attribute, value, timestamp, description}

• ~~\[ \] MQTT客户端（连接到Node-RED、家庭助理等）~~ — Difficulty: 4 | Effort: L

> *从应用程序中无法直接实现。* 联系人 interfaces.mqtt API仅适用于驱动程序，不适用于应用程序。Groovy沙箱也不允许 java.net.Socket 或用于自定义MQTT实现的任意Java导入。 > > 替代方案：同伴驾驶员进场 *（添加到下面）*

• \[ \] MQTT通过配套驱动程序 *（直接MQTT的替代方案）* — Difficulty: 4 | Effort: L

> *通过变通方法可行。* 创建自定义 MCP MQTT Bridge Driver 使用 interfaces.mqtt 连接到经纪人。MCP应用程序通过以下方式将此驱动程序创建为子设备 addChildDevice().通信通过设备命令（应用程序→驾驶员： publish(topic, message))和事件（驾驶员→app: sendEvent() + subscribe()).这将向项目添加第三个Groovy文件。 > > 实施计划： > > 1. 创建 MCP MQTT Bridge 司机与 interfaces.mqtt > 1. 驱动程序公开命令： connect, disconnect, publish, subscribe > 1. 驱动程序根据传入消息和连接状态触发事件 > 1. 父应用程序通过以下方式创建驱动程序实例 addChildDevice() > 1. 添加 mqtt_publish, mqtt_subscribe, mqtt_status MCP工具 > 1. 将驱动程序添加到HPM包清单 > > 替代方案（更简单）： 使用现有 http_request 通过HTTP-to-MQTT网关（Node-RED HTTP-in节点、HiveMQ REST API、EMQX REST API）桥接的操作。

______________________________________________________________________

高级自动化模式

这些模式不需要新的MCP工具——人工智能助手已经可以使用现有的MCP工具来组合它们了 custom_create_rule, set_variable, create_virtual_device以及其他工具。它们在这里被记录为参考模式，显示了当前规则引擎可以实现的目标。除非确定了特定的差距，否则不计划使用专用的向导工具。

• \[ \] 占用/房间状态机 — No new tools needed

> *已经可以实现了。* AI可以使用现有的基元来组合它：一个hub变量 roomState_ 保持状态（空置/占用/占用/检查）。 device_event 运动/接触传感器上的触发器输入 if_then_else 链条与 set_variable 状态转换操作。基于持续时间的触发器处理超时。其他规则通过以下方式检查房间状态 variable 条件。不需要专用工具——人工智能可以根据要求使用 custom_create_rule 和 set_variable.

• \[ \] 基于状态的自动化（先到达，最后离开） — No new tools needed

> *已经可以实现了。* AI可以组成这个：一个中心变量 homeCount 追踪在场的人。 device_event 存在传感器上的触发器通过以下方式递增/递减 variable_math.规则与 variable 条件火灾时 homeCount 转换0→1 （首次到达）或1→0 （最后一次离开）。所有的积木今天都存在。

• \[ \] 基于天气的触发器 — No new tools needed

> *天气设备驱动程序已经可以实现。* 许多Hubitat用户安装了天气驱动程序（OpenWeatherMap、weather Underground等），将天气数据作为设备属性公开。如果用户在MCP中选择天气设备，则可以通过以下方式触发 device_event 触发器和 device_state 条件——无需更改代码。对于没有天气驱动程序的用户，人工智能可以创建一个 periodic 规则 http_request 轮询天气API并将结果存储在中心变量中的操作。

• \[ \] 度假模式（随机光循环、自动锁定、节能） — No new tools needed

> *已经可以实现了。* AI可以使用现有的原语来组合它： mode_change 触发→ capture_state +锁定命令+恒温器设定点。A. periodic 触发器 mode 条件循环随机灯（规则引擎具有 repeat 行动和 delay 具有可变偏移）。模式返回触发器 restore_state. new Random() 在沙箱中可用于随机计时。所有的积木今天都存在。

______________________________________________________________________

监测和诊断

• \[ \] 设备健康监视器 — Difficulty: 2 | Effort: S

> *可行。* 现有的 device_health_check 该工具仅按需提供。增强：添加一个定期的背景检查（每4-6小时一次），主动检测陈旧/离线设备和低电量。通过通知设备推送警报。将结果写入CSV进行趋势分析。火a mcpDeviceHealthAlert 规则集成的位置事件。 > > 实施计划： > > 1. 添加 schedule("0 0 */6 ? * *", "runHealthWatchdog") 到父应用程序 > 1. 重用 toolDeviceHealthCheck() 逻辑 > 1. 添加电池监测：检查 device.currentValue("battery") 对于低水平 > 1. 发送新的陈旧/低电量设备的通知 > 1. 火 sendLocationEvent(name: "mcpDeviceHealthAlert") 用于规则集成 > 1. 记录到CSV进行趋势跟踪

• \[ \] Z-Wave重影设备检测 — Difficulty: 3 | Effort: M

> *部分可行（仅检测）。* 通过以下方式获取Z-Wave节点表 /hub/zwaveDetails/json，与设备列表进行交叉引用，并识别没有匹配设备或状态失败的节点。自动删除是不可能的——重影删除需要集线器的web UI Z-Wave详细信息页面。 > > 实施计划： > > 1. 创建 detect_zwave_ghosts MCP工具（需要集线器管理员读取） > 1. 获取Z-Wave节点表和设备列表 > 1. 交叉引用：没有deviceId或失败状态的节点是重影 > 1. 返回带有重影节点和推荐手动操作的报告 > 1. 链接到集线器UI Z-Wave详细信息页面进行修复

• \[ \] 事件历史/分析 — Difficulty: 3 | Effort: M–L

> *部分可行。* 7天的限制 eventsSince() 是平台约束。对于更长的历史记录：添加一个后台调度程序，定期对设备状态进行采样，并写入文件管理器中的CSV文件。用于分析：根据可用历史数据计算事件频率、状态持续时间百分比、数字属性的最小/最大/平均值。在沙箱中，跨设备相关性的计算成本很高。 > > 实施计划： > > 1. 创建 analyze_device_history 用于分析现有7天数据的MCP工具 > 1. 添加定时CSV日志记录，用于长期设备状态采样 > 1. 计算统计：事件频率、状态持续时间%、数字最小值/最大值/平均值 > 1. 按设备返回结构化分析 > 1. 注意：计算量大的分析可能会在许多设备上超时

• \[x\] 集线器性能趋势监控 — Difficulty: 1 | Effort: S

> *大部分已经实施。* 这 get_set_hub_metrics 该工具将快照记录到CSV，维护一个500点滚动窗口，返回可配置的趋势点，并包括阈值警告。 增量增强： 添加定时定期采样（每4小时一次），而不是仅在AI调用工具时进行记录。添加趋势方向分析（变化率、衰退记忆检测）。 > > 实施计划（增量）： > > 1. 添加 schedule("0 0 */4 ? * *", "recordPerformanceSnapshot") 养育 > 1. 添加趋势分析：比较最新N个点的变化方向/变化率 > 1. 对持续下降趋势（而不仅仅是当前的阈值）发出警报

______________________________________________________________________

通知增强功能

• \[ \] 与优先级别的Pushover集成 — Difficulty: 2 | Effort: M

> *可行。* 简单 httpPost() 到 https://api.pushover.net/1/messages.jsonHubitat生态系统已经有了内置的Pushover驱动程序，但直接的API集成提供了更多的控制（优先级-2到2，声音，补充URL，紧急重试/过期）。 > > 实施计划： > > 1. 将Pushover API密钥和用户密钥添加到应用程序首选项 > 1. 创建 send_pushover 带消息、标题、优先级、声音参数的MCP工具 > 1. httpPost() 到带有表单编码主体的Pushover API > 1. 对于紧急优先级（2），包括 retry 和 expire 参数 > 1. 添加为规则操作的通知通道

• \[ \] 通过SendGrid发送电子邮件通知 — Difficulty: 2 | Effort: M

> *可行。* JSON POST到 https://api.sendgrid.com/v3/mail/send 使用Bearer令牌身份验证。现有代码已经使用自定义标头执行JSON POST（节省空间的代码使用 requestContentType: "application/json"). > > 实施计划： > > 1. 将SendGrid API密钥、发件人电子邮件、默认收件人添加到应用程序首选项 > 1. 创建 send_email 带to、subject、body、可选html参数的MCP工具 > 1. httpPost() 到带有JSON主体和Bearer-auth头的SendGrid v3 API > 1. 添加为规则操作的通知通道

• \[ \] 速率限制/节流 — Difficulty: 2 | Effort: S

> *可行。* 使用纯应用内逻辑 state/atomicState 和 now().存储每个通道最近通知的时间戳。发送前检查冷却情况。遵循现有的循环保护模式进行滑动窗口速率限制。可配置每通道冷却和每小时最大限制。 > > 实施计划： > > 1. 添加 state.notificationHistory 跟踪每个通道的时间戳 > 1. 每次发送通知前检查冷却情况 > 1. 在应用首选项中添加可配置的阈值 > 1. 当速度受限时，在工具响应中返回油门状态

• \[ \] 按严重程度划分的通知路由 — Difficulty: 3 | Effort: M

> *可行。* 定义严重程度（信息/警告/严重/紧急）。将每个严重性映射到应用程序首选项中的通知通道。发送到适当的渠道。取决于Pushover和SendGrid是否首先实现。 > > 实施计划： > > 1. 定义严重级别：信息、警告、严重、紧急 > 1. 在应用程序首选项中为频道路由添加严重性 > 1. 创建 send_alert 带有消息和严重性参数的MCP工具 > 1. 路由逻辑读取配置并分派到匹配的通道 > 1. 每个通道（Pushover、SendGrid、集线器通知设备）都是一个单独的方法

______________________________________________________________________

其他想法

• \[ \] 独立虚拟设备创建（独立于MCP应用程序） — Difficulty: 2 | Effort: S–M

> *可行但未经证实。* 集线器内部API POST /device/save 可能支持通过以下方式创建设备 id="" （Grails约定）。创建的设备将出现在常规设备部分，即使卸载了MCP，该设备也会持续存在。然而：这个端点是为了更新而不是创建而记录的——需要实证测试。内置的驱动程序类型ID可能无法通过以下方式发现 /hub2/userDeviceTypes. > > 实施计划： > > 1. 测试 /device/save 随着 id="" 关于实际的集线器硬件 > 1. 发现虚拟交换机、虚拟调光器等的内置驱动程序类型ID。 > 1. 创建 create_standalone_device MCP工具（需要集线器管理写入） > 1. 注意：未经用户选择，设备不会自动出现在MCP的设备列表中 > 1. 回退：使用现有 create_virtual_device 随着 isComponent: false

• \[ \] 场景管理（创建/修改activate_Scene之外的内容） — Difficulty: 3 | Effort: M

> *部分可行。* 本地组和场景CRUD是不可能的（没有API）。然而，现有 capture_state/restore_state 该系统已经是一个事实上的场景管理器。增强：使用面向场景的术语进行包装-- create_scene （捕获）， list_scenes （列表捕获）， activate_scene （恢复）， delete_scene （删除捕获）。将捕获的属性扩展到开关/级别/颜色之外，以包括风扇速度、阴影位置、恒温器设定点。 > > 实施计划： > > 1. 创建场景别名工具，包装现有的捕获状态工具 > 1. 扩展 capture_state 保存其他属性（风扇速度、遮阳帘位置、恒温器） > 1. 添加 modify_scene 在现有场景中重新捕获特定设备的工具 > 1. 记录这些是MCP管理的场景，而不是本地Hubitat场景

• \[ \] 能源监测仪表板 — Difficulty: 3 | Effort: M

> *可行。* 创建一个 get_energy_summary 聚合工具 power 和 energy 所有支持PowerMeter/EnergyMeter的设备的属性。为趋势数据添加预定的CSV日志记录。“仪表板”是MCP上下文中的JSON摘要（无UI呈现），但可以选择将HTML文件写入文件管理器，可在 http:///local/energy-dashboard.html. > > 实施计划： > > 1. 创建 get_energy_summary MCP工具 > 1. 查找所有具有PowerMeter/EnergyMeter功能的设备 > 1. 当前总功率（W）和累计能量（kWh） > 1. 按设备细分和总计返回 > 1. 为能源趋势数据添加预定的CSV记录器 > 1. 可选：为可视化仪表板生成静态HTML文件

• \[ \] 计划自动报告 — Difficulty: 3 | Effort: M

> *可行。* 计划通过 schedule() 使用cron表达式。报告汇总了来自现有监控工具的数据（设备运行状况、集线器性能、规则活动）。以JSON格式保存到文件管理器。通过通知设备推送摘要。对于电子邮件传递，请使用SendGrid集成（如果已实现）或 httpPost() 对外服务。 > > 实施计划： > > 1. 添加 configure_report_schedule MCP工具 > 1. 定义报告模板：集线器运行状况、设备状态、规则活动、能量 > 1. 通过以下方式安排 schedule() 使用用户配置的cron表达式 > 1. 从现有工具方法中聚合数据 > 1. 将完整报告以JSON格式保存到文件管理器 > 1. 通过配置的通道推送摘要通知

• ~~\[ \] 设备配对辅助（Z-Wave、Zigbee、云）~~ — Difficulty: 4 | Effort: L

> *不适用于主动配对。* 设备配对（Z-Wave包含，Zigbee配对）是一种交互式、实时的无线电级操作。该中心的Z-Wave/Zigbee包含模式端点没有记录，配对是一个多步骤、对时间敏感的过程，与MCP的请求-响应模型不兼容。云集成需要OAuth UI流。 > > 替代方案：配对指导工具 *（添加到下面）*

• \[ \] 设备配对指南 *（主动配对的替代方案）* — Difficulty: 2 | Effort: S

> *可行。* A. guide_device_pairing 该工具提供使用Hubitat web UI配对设备的分步文本说明。配对后，AI可以使用现有的MCP工具帮助配置设备（驾驶员选择、房间分配、标签、偏好），如 update_device, send_command，以及房间管理工具。 > > 实施计划： > > 1. 创建 guide_device_pairing MCP工具 > 1. 接受设备类型（Z-Wave、Zigbee、云）和可选型号信息 > 1. 返回分步说明，并直接链接到集线器UI页面 > 1. 配对后，通过现有的MCP工具进行配置

______________________________________________________________________

不可行项目总结

由于平台限制，以下项目已被确定为无法实现。它们在这里列出，并附有解释和添加到上述计划中的替代方案。

• ~~群组和场景（Zigbee群组消息）~~--那个 zigbee 对象和 sendHubCommand(Protocol.ZIGBEE) 是仅限驱动程序的API。Zigbee组管理不存在HTTP端点。 → 通过以下方式使用软件组命令或内置的“组和场景”应用程序的激活器设备 send_command

• ~~MQTT客户端（直接）~~ — interfaces.mqtt 只有司机。应用程序中没有原始TCP套接字。 → 作为替代方案，添加了同伴驾驶员方法

• ~~设备配对辅助（活动）~~--广播包容性是互动性的，没有记录。MCP的请求-响应模型无法处理多步骤配对流。 → 添加配对指导工具作为替代

______________________________________________________________________

建议的实施优先级

基于用户价值与实施努力的比率。不包括人工智能已经可以使用现有工具（占用、在场、度假模式、天气以及模式管理器、按钮控制器等原生应用程序等效物）组合的项目。

第一阶段：速赢（小努力，高价值）

1. 规则机器互操作性 （列表、控件、触发器、布尔值）--全部使用 RMUtils，作为1-2个工具实施
2. 本地中心变量更改触发器 — subscribe(location, "variable:", handler) + addInUseGlobalVar() 注册
3. ICMP 回显请求 --完成；折叠成 device_health_check 通过 pingHosts/pingCount （第91期）
4. 搜索HPM存储库 -Public GraphQL API，即时发现价值
5. 速率限制/节流 --纯应用内逻辑，实现更安全的通知
6. 系统启动触发器 --单身 subscribe() 呼叫
7. 日期范围条件 --遵循现有条件模式
8. 设备健康监视器 --将计划任务添加到现有工具
9. 每个规则的私有布尔值 --通过家长调解进行跨规则协调
10. 禁用/启用设备操作 --包装现有 update_device 能力
11. 文件写入/追加/删除操作 --包装现有父文件方法
12. 音乐/警报器控制动作 --便利包装 device_command

第2阶段：核心增强（中等努力，高价值）

1. Webhook触发器 --新端点+触发器类型
2. 事件流/webhooks --订阅+异步帖子
3. Pushover集成 -简单的API集成
4. 通过SendGrid发送电子邮件 -简单的API集成
5. 褪色调光器/色温 --共享坡道公用设施
6. 规则到规则控制 --家长调解，现有方法
7. 通知路由 --Pushover/SendGrid之上的层
8. Z-Wave重影检测 --节点表对照
9. 可变变更事件 --变量写入时的位置事件
10. 按模式操作 --多分支动作类型

第三阶段：高级功能（大工作量，专业价值）

1. 布尔表达式生成器 --递归树评估+迁移
2. 必需的表达式/门 --持续监控架构
3. MQTT通过配套驱动程序 --第三个文件，驱动程序开发
4. 仪表板创建/修改/删除 --内部端点方法，需要中心测试
5. 计划的报告 --聚合+调度+交付
6. 能源监测 --跨设备的总功率/能量
7. 场景管理 --围绕捕获状态的面向场景的包装

第4阶段：探索性（需要测试或存在重大局限性）

1. 等待事件/表达式 --复杂状态持久性
2. 重复直到 --回路安全问题
3. 轮毂可变连接器 --自定义驱动程序依赖关系
4. 通过HPM安装软件包 --HPM同步碎片
5. 独立虚拟设备 -API终结点未经验证
6. 事件历史/分析 --平台7天限制

低优先级：本地应用等效物（仅当发现MCP交互差距时）

1. 房间照明 --使用本地应用程序；审查MCP是否不能与其效果相互作用
2. 区域运动控制器 --使用本地应用程序；MCP已经可以看到其虚拟设备
3. 模式管理器 --使用本地应用程序；MCP已读取/设置模式
4. 按钮控制器 --使用本地应用程序；MCP已经 button_event 触发器
5. 恒温器调度器 --使用本地应用程序；MCP已经 set_thermostat 行动
6. 锁码管理器 --使用本地应用程序；审查如果 send_command 证明不足

______________________________________________________________________

版本历史

• v1.3.1 -壮举：为问题模板、作用域日志、公共安全模式重新生成generate_bug_report。PR： #182
• v1.2.1 -feat（manage_app_driver_code）：库管理（安装/更新/删除/获取源代码）。PR： #164
• v1.2.0版本 -壮举：通过Hubitat appCloner添加clone/export/import_native_app。PR： #158
• v1.1.1 -ci：将合并后的自动化整合到发布工作流中（关闭竞赛）。PR： #160
• v1.1.0版本 -feat（devices）：添加poll_until_attribute——阻止轮询，直到属性匹配；第92页。PR： #157
• v1.0.4 -feat（列出设备）：服务器端标签/功能过滤器+格式/字段投影。PR： #153
• v1.0.3 -feat（规则工具）：当调用者传递内置RM规则id时重定向提示（地址#118选项a）。PR： #135
• v1.0.2 -docs：为AI贡献者添加AGENTS.md；第91页。PR： #149
• v1.0.1 -feat:可选的平面工具列表模式（关闭类别网关）。PR： #136
• v0.9.6 -修复：从packageManifest.json releaseNotes中删除PR引用。PR： #80
• v0.9.5 -壮举：在发行说明中包含PR主提交扩展描述。PR： #78
• v0.9.3 -发布自动化：机器人驱动的版本碰撞+CHANGELOG+发布说明同步。PR： #66
• v0.9.2 -丰富 list_devices 摘要（新字段： disabled, deviceNetworkId, lastActivity, parentDeviceId)+服务器端 filter arg(enabled / disabled / stale:)在分页之前应用——关闭常见批量问题的N+1往返问题。修复 get_hub_logs 排序（现在先返回最近的条目；以前从环形缓冲区返回最旧的条目）+新 deviceId / appId 服务器端作用域参数（作用域时有效负载减少约93%）。
• v0.9.1 新 search_tools：在所有74个MCP工具（核心+网关子工具）中进行BM25自然语言搜索。搜索工具名称、描述和参数名称。返回按与网关归因的相关性排序的匹配工具，以便LLM知道如何调用它们。受FastMCP 3.1工具搜索变换的启发。总共74个MCP工具（31个 tools/list).
• v0.9.0版本 -新工具： get_performance_stats （设备/应用程序性能统计数据——方法调用计数、繁忙百分比、累计总毫秒数、状态大小、事件、大状态标志；可按排序 pct/count/stateSize/totalMs/name)以及 get_hub_jobs （计划/运行作业、中心操作），两者都在 manage_logs 网关。增强 get_memory_history: limit 参数（默认值100）用于防止响应错误过大，现在包括Java堆(totalJavaKB, freeJavaKB)以及直接/NIO缓冲存储器(directJavaKB)每个条目都有泄漏检测的最小/最大跟踪摘要。总共73个MCP工具（30个 tools/list).
• v0.8.7 -添加内存诊断工具： get_memory_history 和 force_garbage_collection，两者都在 manage_diagnostics 网关。总共71个MCP工具。
• v0.8.6 -Bug修复： days_of_week 条件崩溃(Date.format(String, Locale) 在Hubitat沙盒中不可用）。

Older versions (v0.7.0 – v0.8.5)

• v0.8.5 -Bug修复：修复 send_command 映射参数处理（Hubitat的JSON解析器阻塞了参数数组中的嵌套JSON对象，退回到原始String——现在通过大括号匹配提取嵌入的JSON对象），修复 get_hub_logs 源过滤器（正在检查时间戳字段而不是消息字段——源搜索从不匹配应用程序/设备名称），在规则操作参数转换器中向Map解析添加JSON字符串
• v0.8.2 -关键错误修复：修复规则操作执行崩溃(log.isDebugEnabled() Hubitat沙箱中不可用-所有规则操作都无声失败），已修复 send_command setColor/map参数处理（JSON字符串参数现在可以自动解析为Maps中的命令，如 setColor 需要Map参数）
• v0.8.1 -Bug修复：删除死代码（toolEnableRule/toolDisableRule/toolToggleRule），修复消息和文档中过时的工具引用，更新BAT-v2以实现最终的9网关架构
• v0.8.0 -类别网关代理：将48个工具整合到9个域名网关后，减少 tools/list 从69岁到30岁。21个核心工具保持未分组状态（设备、规则、模式、HSM、update_device、manage_virtual_vice、list_virtual-devices、get_hub_info、create_hub_backup、check_for_update、generate_bug_report、get_tool_guide）。将get_hub_health和get_hub_details合并为get_hub_info——全面的中心信息（硬件、健康、MCP统计数据）始终可用；在Hub Admin Read后面门控的PII/位置数据（名称、IP、时区、坐标、邮政编码）。将enable_rule/disable_rule合并到update_rule中（使用 enabled=true/false).将创建虚拟设备/删除虚拟设备合并到管理虚拟设备中（使用 action 枚举）。将create_hub_backup、check_for_update和generate_bug_report提升到核心工具。解散manage_hub_info网关（无线电详细信息移动到manage_dignostics）。将manage_hub_manuance重命名为manage_destructive_hub_ops，manage_code_更改为manage_app_driver_code。每个网关在其描述中显示带有参数提示的工具摘要（LLM始终可见），并根据需要返回完整的模式。网关：manage_rules_admin、manage_hub_variables、manage_room、manage_destructive_hub_ops、manage_apps_driver_code（只读）、manage_logs、manage_dignostics、manage_files。以ha mcp PR#637为蓝本。重大变化：从中删除代理工具 tools/list 但可通过网关访问。
• v0.7.7 -代码审查第2轮：MCP协议修复（工具错误使用每个规范的isError标志），修复formatAge（）奇异语法，短路条件评估，修复基于CI的双动，整合冗余API调用，保护紧急调试日志记录，消除重复的日出/日落重新安排，修复variable_math双原子状态读取，提高效率
• v0.7.6 -代码审查：修复hoursGo计算错误，修复变量阴影，集中版本字符串，提取共享助手（减少约90行）
• v0.7.5 -代币效率：通过渐进式披露的精益工具描述 get_tool_guide （代币减少约27%）
• v0.7.4 -稳定性：可配置的执行循环保护，带有推送通知、安全室移动、弹性日期解析
• v0.7.3 -文档同步（SKILL.md节名称与源代码结构匹配）
• v0.7.2 -设备授权安全+优化的工具描述+get_tool_guide（74个工具）
• v0.7.1 -delete_rule、testRule标志的自动备份，错误修复
• v0.7.0 -房间管理：list_Room、get_Room、create_Room、delete_Room、重命名_Room（73个工具）

Older versions (v0.0.3 – v0.6.15)

• v0.6.15 -房间分配修复：使用“roomId”字段（不是“id”），在添加到新房间之前从旧房间中删除
• v0.6.14 -房间分配：POST/Room/save，JSON内容类型，表单编码，hub2/前缀，Grails命令对象
• v0.6.13 -房间分配：尝试PUT/Room（Grails RESTful更新）、POST/Room/save、POST/Room/update、probe/Room/list进行端点发现
• v0.6.12 -修复房间分配：使用GET/room/addDevice查询参数+验证
• v0.6.11 -修复房间分配：使用/房间/控制器端点（将设备添加到房间）
• v0.6.10 -修复房间分配：对/device/save使用fullJsondevice数据（Vue.jsSPA没有HTML表单）
• v0.6.9 -房间分配：抓取设备编辑页面HTML以获取正确的表单字段
• v0.6.8 -房间分配：捕获500个错误响应体进行诊断
• v0.6.7 -修复房间分配：添加Grails version 乐观锁定字段
• v0.6.6 -房间分配：使用设备JSON转储进行诊断构建
• v0.6.5 -修复房间分配：使用 deviceTypeId 字段（非 typeId)
• v0.6.4 -修复房间分配：从嵌套中提取设备数据 fullJson.device
• v0.6.3 -修复 update_device 房间分配（500）和启用/禁用（404）错误+调试日志
• v0.6.2 -添加 update_device 工具（68个工具）
• v0.6.1 -修复版本更新检查器中BigDecimal.round（）崩溃的问题（67个工具）
• v0.6.0 -虚拟设备创建和管理（67个工具）
• v0.5.4 -用纯整数数学修复BigDecimal算法 device_health_check 和 delete_device （64工具）
• v0.5.3 -修复 BigDecimal.round() 在 device_health_check （64工具）
• v0.5.2 -修复 device_health_check 错误处理（64个工具）
• v0.5.1 -修复 get_hub_logs JSON数组解析（64个工具）
• v0.5.0 -监控工具和设备管理（64个工具）
• v0.4.8 -修复Z-Wave和Zigbee端点兼容性（59个工具）
• v0.4.7 -从代码审查中全面修复错误（59个工具）
• v0.4.6 -修复乐观锁定中的版本不匹配错误（59个工具）
• v0.4.5 -智能大文件处理（59个工具）
• v0.4.4 -修复Claude.ai实时测试中发现的错误（59个工具）
• v0.4.3 -全面的错误修复+项目备份和文件管理器工具（59个工具）
• v0.4.2 -响应大小安全限制（集线器强制128KB上限）
• v0.4.1 -Hub Admin工具+两层备份系统的错误修复
• v0.4.0 -支持集线器安全的集线器管理工具（52个工具）
• v0.3.3 -多设备触发器支持和验证修复
• v0.3.2 -全面的错误修复（已验证并修复25个错误）
• v0.3.1 -来自v0.3.0全面测试的Bug修复
• v0.3.0 -规则可移植性、新动作类型、条件触发器（34个工具）
• v0.2.12 -第四次代码审查：关键UI错误修复+16个额外错误修复
• v0.2.11 -第三次代码审查（16次修复）
• v0.2.10 -固定操作员操作
• v0.2.9 -第二次彻底审查中的关键错误修复
• v0.2.8 -彻底的代码审查修复
• v0.2.7 -修复了应用安装/打开时的StackOverflow错误
• v0.2.6 -已添加 generate_bug_report 工具
• v0.2.5 -添加了MCP调试日志级别的UI控件
• v0.2.4 -已将版本字段添加到 get_logging_status
• v0.2.3 -HPM版本升级
• v0.2.2 - 关键修复：规则 enabled=true 现在坚持正确
• v0.2.1 -修复重复 formatTimestamp 方法编译错误
• v0.2.0版本 -MCP调试记录系统（5个新的诊断工具）
• v0.1.23 -规则创建顺序的关键修复
• v0.1.22 -主要错误修复：操作返回、验证、类型强制
• v0.1.21 -修复了负指数漏洞，零安全改进
• v0.1.20 -已添加 handlePeriodicEvent()，固定 cancel_delayed，7种缺失条件类型
• v0.1.19 -已修复 time_range 字段名兼容性
• v0.1.18 -已删除 expression 条件类型（沙盒中不允许）
• v0.1.17 -UI/MCP奇偶校验：6种条件类型+12种操作类型添加到UI中
• v0.1.16 -固定持续时间触发重新武装
• v0.1.15 -修复了规则创建时的“必填字段”验证错误
• v0.1.14 -修复了子应用标签不更新的问题
• v0.1.13 -修复了Hubitat沙盒兼容性
• v0.1.12 -性能改进，可配置的捕获状态限制
• v0.1.11 -在工具描述中添加了验证提醒
• v0.1.10 -修复了设备标签返回null的问题
• v0.1.9 -修复了缺少条件类型验证的问题
• v0.1.8 -固定持续时间触发反复射击
• v0.1.7 -基于固定持续时间 device_event 触发器
• v0.1.6 -已修复 repeat 动作参数名称
• v0.1.5 -已修复 capture_state/restore_state 跨越规则
• v0.1.4 -添加了剩余的记录操作
• v0.1.3 -主要规则引擎修复
• v0.1.2 -修复了缺失的动作类型
• v0.1.1 -添加了分页 list_devices
• v0.1.0 -父/子架构
• v0.0.6 -固定触发/条件/动作保存流
• v0.0.5 -设备和可变工具的错误修复
• v0.0.4 -添加了完整的规则引擎UI
• v0.0.3 -首次发布

______________________________________________________________________

Manual Testing Checklist

UI规则管理

• \[\]通过Hubitat应用程序>MCP规则服务器>添加规则创建新规则
• \[\]通过UI编辑现有规则触发器
• \[\]通过UI编辑现有规则条件
• \[\]通过UI编辑现有规则操作
• \[\]通过UI切换启用/禁用规则
• \[\]删除带有确认对话框的规则
• \[\]使用“测试规则”按钮（模拟运行）验证规则逻辑
• \[\]验证规则列表是否正确显示状态和上次触发时间

触发器配置UI

• \[\]添加device_event触发器并选择设备/属性
• \[\]添加按钮编号选择的按钮事件触发器
• \[\]使用时间选择器添加时间触发器
• \[\]添加带有偏移输入的日出/日落触发器
• \[\]添加具有间隔配置的周期性触发器
• \[\]添加模式选择的mode_change触发器
• \[\]添加带有状态选择的hsm_change触发器

条件配置界面

• \[\]添加带有操作员选择的device_state条件
• \[\]使用开始/结束时间选择器添加time_range条件
• \[\]添加多模式选择的模式条件
• \[\]添加带日期复选框的days_of-week条件
• \[\]添加变量名输入的变量条件
• \[\]测试条件逻辑在“所有”和“任何”之间切换

动作配置UI

• \[\]使用命令下拉菜单添加device_command操作
• \[\]添加具有秒输入的延迟操作
• \[\]使用级别滑块添加set_level操作
• \[\]添加具有嵌套动作配置的if_then_else动作
• \[\]添加具有范围选择的set_variable操作
• \[\]验证操作重新排序是否正常工作

测试

这 tests/ 目录包含：

• tests/BAT-v2.md --行为接受测试（BAT）：针对实时中心进行手动验证的脚本场景。包括 wizard_probe 使用文档和向导状态回归附录。
• tests/sandbox_lint.py --Groovy沙箱模式的快速结构lint（禁止调用、版本字符串一致性）。运行通过 uv run --python 3.12 tests/sandbox_lint.py.
• tests/e2e_test.py --对带电集线器进行端到端烟雾测试。需要 tests/e2e_config.json （忽略了）。运行通过 uv run --python 3.12 --with requests tests/e2e_test.py.
• tests/wizard_probe.py --系统规则机向导状态回归探测。运行一个25探测矩阵，该矩阵练习可疑的向导状态泄漏路径，并公开 quick_probe() 一次性诊断调查的助手。请参阅中的wizard_probe附录 tests/BAT-v2.md 完全使用。
• Spock单元测试 在...之下 src/test/groovy/ --通过Gradle包装器运行：

./gradlew test

看 docs/testing.md 有关完整的Spock线束概述，如何添加新规范，以及RMUtils的模拟配方 manage_native_rules_and_apps 工具。

贡献

欢迎投稿！分叉仓库，创建功能分支，进行更改，并提交拉取请求。

新的MCP工具必须随附单元测试 --黄金路径和错误路径覆盖。工具处理程序测试正在进行中 src/test/groovy/server/；规则引擎测试 src/test/groovy/rules/。参见 docs/testing.md 对于线束概述，添加新工具规范的配方，以及RMUtils的模拟模式 manage_native_rules_and_apps-样式工具。

添加工具而不进行测试的PR将被要求在合并之前添加它们。CI(./gradlew test)通过以下方式在每个PR上运行 .github/workflows/unit-tests.yml.

许可证

MIT许可证-请参阅 许可证

致谢

• 在以下人员的协助下建造 克劳德 （人类学）
• 灵感来自 模型上下文协议
• 灵感来自 家庭助理MCP
• 感谢Hubitat社区提供的文档和示例

免责声明

本软件按“原样”提供，不提供任何形式的保修。这是一个人工智能辅助的项目，可能包含错误或意外行为。始终仔细测试自动化，尤其是那些控制关键设备的自动化。作者不对使用此软件造成的任何损坏或问题负责。