是否考虑针对设备的特定转换规则？

[NXY666]

通过自动转换规则，可以解决大部分设备的实体生成

但是，很多设备的定义十分混乱（有的还很反人类）

同样是开关，有的是点击方式为实体，按键为属性；有的是按键为实体，点击方式是属性；有的就是排列组合，全部用实体。

不同品牌、相同功能的实体，命名的用词也不同。

是否可以定义一个标准，然后可以根据这个标准，对各个设备设置进行针对性的规则转换。

如果制作一个规则有详细的文档和教程，即使完全依赖社区进行改进，或许也能有不错的效果。

这样还能解决所有实体都在“控制”分类，“配置”分类未使用的问题。

[SusanPhevos]

MIoT-Spec-V2 有标准，但是厂商不按标准定义或实现，小米 IoT 平台无法阻拦。
如果像 Homekit 一样对协议规范有强制性认证测试，又会打击厂商接入米家 APP 的积极性，推行很困难。

[NXY666]

MIoT-Spec-V2 有标准，但是厂商不按标准定义或实现，小米 IoT 平台无法阻拦。
如果像 Homekit 一样对协议规范有强制性认证测试，又会打击厂商接入米家 APP 的积极性，推行很困难。

这个我能理解，不可能强制要求厂家按规范实现。

我的想法是再加一层针对特定品牌、特定产品的针对性转换规则。

以下是一些我想到的几个场景：

1. 比如说不同品牌对于某个功能，取名不一样，可以通过这套转换规则把它们命名成一样的（包括选项）。

2. 还有比如说小米音响那个监听对话内容的API，用的是http轮询，也可以通过这一层实现。

3. ha实际上有不同的实体类型，目前几乎所有可控制实体都在“控制”类别下，但是还有“配置”类别可用（这方面我研究的不深，可能有理解错误）。之前我有遇到关灯会把指示灯一起关掉，后来指示灯改为归类在“配置”下，它就不会被自动化影响。我想这种完全靠通用的协议转换来实现比较困难，还是得通过特定的转换规则来实现。

4. 现在仍有不少设备的实体会在重启后出现状态变更，导致误触自动化，必须通过not_to条件规避（加了就没法用ha的可视化编辑器了），这其实是一个比较麻烦的情况，或许可以通过某种特定的针对性规则来忽略这种不必要的变更。