v0.3.1 — 修复日志级别

🔇 日志级别修复

v0.3.0 的日志降级有 bug（多行匹配失败），这次用 regex DOTALL 修复了。

效果

正常运行时默认日志里基本看不到 bemfa_cloud 的日志，只有真正出错时才会出现 WARNING。

降级统计

文件	WARNING（仅错误）	DEBUG（正常操作）
tcp.py	3	17
service.py	2	28
config_flow.py	3	16
http.py	1	7
sync.py	0	3

📥 升级方法

HACS 升级到 v0.3.1，重启 HA

v0.3.0 — 里程碑版本

🎉 v0.3.0 里程碑版本

改名

• 'Bemfa Cloud (Type Override Fork)' → 'Bemfa Cloud (修改版)'
• README 标题同步更新

同步官方 0.1.10

• ✅ 更新 brand 图标（BeHome 品牌图标）
• ✅ 删除 CHANGELOG.md（官方已删除）
• ✅ 所有官方 0.1.6 → 0.1.10 的代码改动已合并

与官方的完整对比

功能	官方 0.1.10	修改版 v0.3.0
基础功能（TCP/创建/同步）	✅	✅
CameraState/VacuumActivity 兼容	✅	✅
OAuth 默认凭据	✅	✅
空调扫风控制	✅	✅
空调 turn_on 修复 (issue bemfa#16)	❌ 未修	✅ 已修
设备类型覆盖	❌	✅
自动删除云端 topic	❌	✅
邮箱+密码自动登录	❌	✅
微信扫码续期	❌	✅
按需获取 Token	❌	✅
热重载不断 TCP	❌	✅
长名称截断	❌	✅
名称同步到巴法云	❌	✅
列表显示巴法云类型	❌	✅

升级方法

HACS 升级到 v0.3.0，重启 HA

v0.2.9 — 同步列表显示巴法云设备类型

✨ 改进

编辑同步配置时，列表里现在能看到巴法云设备类型了：

之前	现在
[switch] 餐厅灯	[switch→灯] 餐厅灯
[light] 客厅灯	[light] 客厅灯（无 override 不变）
[switch] 书房灯	[switch→灯] 书房灯

箭头（→）清楚显示了从 HA 实体类型到巴法云设备类型的映射。没有设置 override 的实体保持原样显示。

📥 升级方法

HACS 升级到 v0.2.9，重启 HA

v0.2.8 — 清理日志级别

🔇 日志级别调整

功能稳定后，把成功路径的诊断日志从 WARNING 降为 DEBUG，只保留真正的错误为 WARNING。

日志级别说明

级别	内容	默认可见
ERROR	_ensure_topics 失败、TCP 订阅失败（中止 restore）	✅
WARNING	TCP 连接失败、API 调用失败、删除失败、Token 过期、消息格式异常	✅
DEBUG	TCP 连接/订阅/发布成功、API 调用成功、restore 流程、config flow 步骤、心跳、原始数据接收	❌

最终统计

文件	WARNING	DEBUG	ERROR
tcp.py	14	6	0
service.py	9	21	2
config_flow.py	3	16	2
http.py	4	4	0
sync.py	0	3	0

如何查看 DEBUG 日志

需要排查问题时，在 HA 里设置自定义日志级别：

设置 → 系统 → 日志 → 自定义日志级别 → 添加 custom_components.bemfa_cloud → debug

📥 升级方法

HACS 升级到 v0.2.8，重启 HA。升级后默认日志会安静很多，只有真正出问题时才会看到 WARNING。

v0.2.7 — 合并官方 0.1.10 扫风控制 + 保留 turn_on 修复

✅ 合并了官方 0.1.10 的扫风控制

同步了官方 bemfa_cloud_ha 0.1.10 的空调扫风（swing）功能：

• 状态发布：空调的左右扫风（l2r）和上下扫风（u2d）状态现在会同步到巴法云
• 反向控制：小爱可以控制空调扫风方向
• 扫风映射：支持 off/horizontal/vertical/both 四种模式

✅ 保留了我们的 turn_on 修复

官方 issue bemfa#16 的空调调温度后模式变自动的问题，官方说"已修复"但用户反馈"还是一样"。我们的 v0.2.6 修复（has_other_fields 检查）比官方更完善，本次合并保留了这个修复。

📋 与官方 0.1.10 的完整对比

功能	官方 0.1.10	我们 v0.2.7
CameraState/VacuumActivity 兼容	✅	✅
OAuth 默认凭据	✅	✅
空调扫风控制	✅	✅ 新合并
turn_on 修复 (issue bemfa#16)	❌ 未修	✅ 我们修了
type override	❌	✅
自动删除云端 topic	❌	✅
邮箱+密码自动登录	❌	✅
微信扫码续期	❌	✅
热重载不断 TCP	❌	✅
长名称截断	❌	✅
名称同步到巴法云	❌	✅

📥 升级方法

HACS 升级到 v0.2.7，重启 HA

v0.2.6 — 修复空调调温度后模式变自动

🐛 Bug 修复

问题：用小爱调空调温度（如调到 23 度），空调模式变成自动，温度变成 26 度。

根因

小爱发来的控制消息：

{"on":true,"t":23}

代码执行顺序：

1. on:true → 调 climate.turn_on ← 问题在这！
2. t:23 → 调 climate.set_temperature(23)

climate.turn_on 会把空调重置成默认模式（自动）和默认温度，然后 set_temperature 虽然设了 23 度，但模式已经被改了。这就是为什么模式变成自动、温度不对。

修复

当消息里有 t/mode/fan 等具体参数时，不调 turn_on。on:true 在这种情况下只是状态指示（设备开着），不是开机命令。

之前：{'on':true,'t':23} → turn_on(重置成自动/26度) → set_temperature(23)
现在：{'on':true,'t':23} → 跳过 turn_on → set_temperature(23) ✅

对应官方 issue

官方 issue #16 报了同样的问题。

📥 升级方法

HACS 升级到 v0.2.6，重启 HA，再用小爱控制空调温度测试。

v0.2.5 — 🔴 修复空调控制崩溃（NameError）

🐛 严重 Bug 修复

根因：v0.2.4 在 sync.py 的 resolve_msg() 里加了 LOGGER.warning() 诊断日志，但忘记在文件头部 import LOGGER。导致每次收到小爱控制消息时立刻崩溃：

NameError: name 'LOGGER' is not defined

现象：

• 小爱发来 {'on':true,'t':24}（设 24 度）
• 巴法云平台短暂显示 24 度
• 但 resolve_msg() 崩溃，set_temperature 服务没调用
• TCP 断开重连，HA 重新发布当前状态（22 度）
• 空调实际没变化

修复：在 sync.py 的 from .const import (...) 里加上 LOGGER。

✅ 修复后预期行为

1. 小爱说"把客厅空调调到 24 度"
2. 巴法云推送 {'on':true,'t':24}
3. resolve_msg() 正常执行，调 climate.set_temperature 设 24 度
4. 空调实际变成 24 度
5. HA 发布新状态 {'on':true,'mode':2,'t':24,'fan':0} 到巴法云

📥 升级方法

HACS 升级到 v0.2.5，重启 HA，再用小爱控制空调测试。

v0.2.4 — 空调控制诊断日志

🔍 诊断版本

你反馈：用小爱设空调 24 度，结果变成了自动模式 26 度。模式和温度都不对。

这个版本把接收消息的日志从 DEBUG 升级到 WARNING，这样默认就能看到小爱发来的控制消息内容。

📥 升级方法

HACS 升级到 v0.2.4，重启 HA

🧪 测试步骤

1. 保持 HA 日志页面打开
2. 对小爱说："小爱同学，把客厅空调温度调到 24 度"
3. 把日志里所有 Bemfa TCP raw received 和 resolve_msg 相关的行贴给我

我会看到：

• 小爱发来的原始消息是什么格式（JSON 还是 # 分隔字符串）
• 走的是哪条解析路径
• 消息里的 mode/温度/fan 值具体是什么

有了这些信息就能定位为什么模式从制冷变成了自动。

v0.2.3 — 修复改名不同步到巴法云

🐛 Bug 修复

你反馈：插件里改了名字（阳台灯→阳台灯1），但巴法云平台上没改。

根因

_ensure_topics 只调 createTopicNoSecret。当 topic 已存在时，API 返回 40006（已存在）但不更新名字。所以改名被静默忽略了。

修复

在 createTopicNoSecret 之后，对每个 topic 额外调一次 modifyName API 更新名字。无论 topic 是新建的还是已存在的，名字都会同步。

📥 升级方法

HACS 升级到 v0.2.3，重启 HA，再试改名。

v0.2.2 — 热重载（配置变更不断 TCP）

🎯 彻底解决配置变更后设备离线

这是所有 writer is None / 设备离线问题的根本修复。

根因

HA 的 add_update_listener 在每次 options 变更时调用 async_reload_entry，它做的是 unload + setup：

1. async_unload_entry → service.async_stop() → 关闭 TCP writer
2. async_setup_entry → 创建新 service + 新 TCP
3. 新 TCP 的 _run() 还没连上
4. _async_restore_syncs() 跑 async_add_syncs()
5. writer 是 None → 订阅失败 → 设备离线

多次快速操作（比如改名+提交）会触发多次 reload，创建 5-8 个竞争的 TCP 连接。

修复

热重载——配置变更时不关 TCP，只更新 config 并重新订阅：

• 如果 service 已存在：更新 self._config，调 _async_restore_syncs()
• TCP 连接保持，writer 一直有效
• topic 在现有连接上重新订阅

效果

• ✅ 改名、改类型、添加/移除同步后设备不再离线
• ✅ 不再有 writer is None 错误
• ✅ 不再有多个竞争的 TCP 连接
• ✅ TCP 连接在配置变更期间保持稳定

📥 升级方法

HACS 升级到 v0.2.2，重启 HA