[Plugin] astrbot_plugin_mihome

[674537331]

插件信息

{
  "name": "astrbot_plugin_mihome",
  "display_name": "米家控制",
  "desc": "AstrBot 的米家云端智能管家插件",
  "author": "RyanVaderAn",
  "repo": "https://github.com/674537331/astrbot_plugin_mihome"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mihome

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

潜在缺陷或问题

• 长列表显示体验不佳：在 mihome_device_detail 方法中，展示的属性列表如果直接拼接（甚至多达40项），可能会导致聊天界面被大段纯文本刷屏，虽然对功能无实质影响，但用户体验较差。
• 回调函数中的异常捕获缺失：在 mihome_login 方法内部定义了 async def cb(url)。在此异步回调中直接执行了 await event.send(...)。如果网络波动导致消息发送失败，该回调内未做 try...except 拦截，可能会在后台产生未捕获的异常日志。

---

_login_worker.py

未发现明显违反框架规范或存在严重安全隐患的问题。代码作为独立的同步子进程脚本，逻辑清晰。

---

data_manager.py

框架适应性检查 - 数据持久化（严重违规）

• 禁止使用非标准路径获取方式与硬编码回退：
  代码中使用了 get_astrbot_data_path 并通过 os.path.join(os.path.abspath(os.getcwd()), "data") 作为 fallback。这严重违反了框架的持久化数据规范。
  修复建议：必须移除顶部的 try...except 导包块。由于 StarTools.get_data_dir() 返回的已经是规范的 data/plugin_data/<plugin_name> 的 Path 对象，应修改架构，在 main.py 中调用 StarTools.get_data_dir() 后将路径对象传入 MiHomeDataManager，或者在 data_manager.py 内部使用框架提供的方法。

  修复示例（推荐在 main.py 层面处理）：

  # main.py
  from astrbot.api.star import StarTools
  # ...
  self.data_dir = StarTools.get_data_dir()
  self.data_manager = MiHomeDataManager(self.data_dir)
  
  # data_manager.py
  from pathlib import Path
  class MiHomeDataManager:
      def __init__(self, data_dir: Path):
          self.data_dir = data_dir
          self.data_dir.mkdir(parents=True, exist_ok=True)
          self.auth_path = self.data_dir / "auth.json"
          self.state_path = self.data_dir / "state.json"
          # ...其余使用字符串路径的地方需统一转为 str() 或支持 Path 的操作

---

mihome_client.py

潜在缺陷或问题

• 可能存在的内存无限增长（Memory Leak Risk）：在 login 方法内部的 read_stdout 协程中，full_buffer += text 持续拼接所有的标准输出内容。虽然在正常扫码登录流程中输出文本量有限，但如果子进程因异常进入死循环并疯狂输出日志，full_buffer 将不断占用内存直到 OOM 崩溃。
  修复建议：由于正则匹配主要是寻找登录 URL，一旦找到就不需要保留旧数据，建议使用固定大小的队列或截断过长的字符串（例如 full_buffer = (full_buffer + text)[-2048:] 保持最后一段即可）。

代码质量与可维护性

• 冗余的类型判断：在 get_devices 方法中，有多处 if not isinstance(own, list): own = []。因为 mijiaAPI 在失败时通常抛出异常，如果确认 API 只返回列表，此处的防御性编程略显臃肿，但属于可接受范围。

---

代码评审团

Linus Torvalds：（揉了揉眉头，敲击着键盘）
“看着你的 data_manager.py，我差点以为我们回到了 1995 年。你写了一个 try-except 去导入一个未暴露的底层路径函数，然后如果失败了，你就直接 os.getcwd()？你是打算把状态文件像垃圾一样随便丢在我的文件系统当前目录里吗？框架文档明确告诉你用 StarTools.get_data_dir()，而且返回的是 Path 对象，你却还在用 os.path.join 拼字符串。重写它，别把事情搞得一团糟。”

乔布斯 (Steve Jobs)：（坐在椅子上，双手合十）
“我们来谈谈你在 mihome_client.py 里的那个 full_buffer。你让它无限期地积累每一个字符，就像一个无底洞。它不优雅。你只想要一个简单的登录链接，对吧？那就截取你需要的那部分，丢掉多余的垃圾。优秀的软件不应该只是‘能跑’，它在内存的管理上必须是极其克制和精确的。把它限制在 2KB 内，让你的代码呼吸。”

GLaDOS：（机械眼闪烁，发出冷漠的电子音）
“哦，真是有趣的测试。你在 main.py 里直接向聊天窗口输出了可能长达 40 个项目的属性列表。我确信人类的眼睛会非常享受在聊天气泡里阅读那一大段毫无排版的测试数据。另外，你在回调函数 cb(url) 里发送消息时，完全没有考虑网络断开导致抛出异常的可能性……不过没关系，看着代码在未捕获的异常中挣扎，一直是我最喜欢的观察项目之一。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 4 个 Python 文件
• 已选择审核文件: 4 / 4
  已发送至 AI 审核的文件清单

main.py
_login_worker.py
data_manager.py
mihome_client.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

当前仓库：674537331/astrbot_plugin_mihome
剩余触发次数：4

[674537331]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mihome

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 米家登录 对 in_progress 状态未做映射处理（逻辑缺陷）
   MiHomeClient.login() 可能返回 {"status": "in_progress"}，但当前 msg 映射表未覆盖该状态，最终会落到 ❌ 错误: None，用户提示错误且不准确。

2. 数据目录依赖硬编码插件名字符串（可维护性问题）
   MiHomeDataManager("astrbot_plugin_mihome") 使用字面量字符串，若 @register(...) 名称变更但此处未同步，可能导致数据目录错位、状态丢失或读取旧目录。

---

_login_worker.py

1. os.makedirs(os.path.dirname(auth_path), exist_ok=True) 存在边界路径异常
   当 auth_path 不含目录（如仅文件名）时，os.path.dirname(auth_path) 为空字符串，makedirs("") 会抛出异常。

2. 异常信息直接回显到标准输出（信息泄露风险）
   except Exception as e: print(f"[WORKER_ERROR] {e}") 会原样暴露内部异常细节（路径、库错误上下文等），不利于最小化错误面暴露。

3. 未使用框架统一日志接口（框架一致性问题）
   文件全程使用 print，未接入 from astrbot.api import logger 的统一日志体系，导致日志采集与排障链路不一致。

---

data_manager.py

1. 未按要求使用 StarTools.get_data_dir() 进行持久化目录管理（框架适配问题）
   当前通过 astrbot_path 或 Path.cwd()/data 拼接目录，不符合指定的数据持久化规范。

2. update_state() 为读-改-写流程，缺少并发保护（异步环境下潜在丢写）
   多个协程同时调用 update_state() 时，可能出现后写覆盖先写，导致状态字段丢失或回退。

---

mihome_client.py

1. logout() / terminate() 对共享状态缺少锁保护（并发一致性问题）
   这两个方法会修改 _login_process、_login_status、self.api，但未统一纳入 _api_lock。在并发命令触发下，可能与 get_devices/control_power/set_property/login 发生竞态。

2. login() 在持有 _api_lock 时等待扫码全过程（潜在性能瓶颈）
   锁持有可能长达 120 秒，期间其他需要 API 的操作会全部阻塞，表现为“插件无响应/排队过久”。

3. terminate() 将 self.api 置为 None，缺少后续调用防护（潜在运行时异常）
   若生命周期管理或异常时序导致终止后仍有调用进入，self.api.login 等会触发 NoneType 错误，当前没有显式短路保护。

---

代码评审团

人物一：Linus Torvalds（刀子嘴，工程洁癖）
“update_state() 这种无锁读改写在并发里就是‘等着丢数据’。状态管理是基础设施，不是玄学。加锁，或者做原子写，不然线上问题会很‘随机’。”

人物二：Steve Jobs（产品体验偏执）
“用户输入 /米家登录，结果看到 ❌ 错误: None，这不是错误提示，这是产品背叛。状态文案必须完整可理解，尤其是 in_progress 这种高频分支。”

人物三：Tony Stark（高压快节奏架构视角）
“你把 _api_lock 持有到扫码超时，等于让整套控制面板在登录时‘冻结’。这不是并发控制，这是全舰停摆。把长等待和关键临界区拆开。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 4 个 Python 文件
• 已选择审核文件: 4 / 4
  已发送至 AI 审核的文件清单

main.py
_login_worker.py
data_manager.py
mihome_client.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

当前仓库：674537331/astrbot_plugin_mihome
剩余触发次数：3

[674537331]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mihome

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 命令前缀解析对前导空白不鲁棒（逻辑边界）
   re.sub(r'^/?米家控制\s*', '', msg)、re.sub(r'^/?米家详情\s*', '', msg) 要求命令必须从字符串开头紧贴出现。若平台上报消息含前导空格（如 " /米家控制 空调 开"），会导致前缀未被剥离，后续解析异常。

2. 异常处理过宽且信息分层不一致（可维护性）
   多处 except Exception 后仅返回“内部错误”或通用文本，部分位置又直接把异常字符串回传给用户。当前策略在“排障可观测性”和“信息暴露控制”之间不一致，后期定位问题会比较困难。

---

_login_worker.py

1. 违反框架日志规范（框架适配性）
   使用了 Python 内置 logging（logging.basicConfig、logging.getLogger），不符合“日志记录器必须且只能从 astrbot.api 导入”的约束。

2. 网络 I/O 为同步阻塞调用（并发模型）
   api.login() 为同步网络调用。该脚本虽然在子进程运行，但从项目整体异步架构角度看，这是显式阻塞式网络流程；若后续复用到主事件循环路径会直接阻塞。

3. 错误输出丢失关键信息（可维护性）
   失败时仅输出异常类型 type(e).__name__，没有异常详情与上下文，导致排障信息不足。

---

data_manager.py

1. 未使用 StarTools.get_data_dir()（数据持久化规范）
   当前通过 astrbot.core.utils.astrbot_path.get_astrbot_data_path / Path.cwd() / "data" 构造目录，未按要求使用 from astrbot.api.star import StarTools + StarTools.get_data_dir() 获取规范插件数据目录。

2. 存在非规范目录回退路径（数据一致性风险）
   ImportError 时回退到 Path.cwd() / "data"，会导致不同部署环境写入位置不一致，影响迁移与运维可控性。

---

mihome_client.py

1. 向上层透传原始异常字符串（潜在信息泄露）
   login() 中 return {"status": "error", "message": str(e)}，以及沙盒退出时回传 full_buffer 片段，可能把内部路径、底层库报错细节直接暴露到聊天侧。

2. 未使用的导入影响代码整洁性（代码质量）
   sys 在该文件中未被使用，属于无效导入，增加维护噪音。

---

代码评审团

人物一：Linus Torvalds（直给型）
你这套主流程思路是清楚的，但 _login_worker.py 里直接上 logging，在有明确框架约束时就是“明知有规矩还绕过去”。建议统一收口日志接口，别让日志体系分裂成两套。

人物二：Steve Jobs（体验洁癖型）
错误信息策略很“割裂”：有时“内部错误”，有时原样回传底层异常。对用户体验来说这不优雅，对安全来说也不克制。建议做统一分层：用户可读文案 + 内部详细日志（仅日志保留细节）。

人物三：福尔摩斯（推理型）
我注意到数据目录来源并不唯一：一条是 core util，一条是 cwd 回退。这会在不同部署路径下制造“同一插件，不同状态”的幽灵问题。建议严格单一来源：StarTools.get_data_dir()，并消除隐式回退分支。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 4 个 Python 文件
• 已选择审核文件: 4 / 4
  已发送至 AI 审核的文件清单

main.py
_login_worker.py
data_manager.py
mihome_client.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

当前仓库：674537331/astrbot_plugin_mihome
剩余触发次数：2

[674537331]

参考插件官方文档与独立子进程考虑，基本差不多了，已完成修改

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#325
已自动合并 PR #325

该插件已上架。
This plugin is now published.