去年买了echo、天猫精灵、小度、叮咚、小爱等智能音箱，想着使用语音控制家里的设备，折腾了好久智能家居技能，发现都有不少的局限：echo的需要用自家服务器、天猫精灵的房间名称太局限、叮咚没有智能家居技能。后来将目光转向了自定义技能，萌生了一个比较优雅接入的想法：音箱平台都统一语义语法，指令让中间服务解析，最后转化为HA的标准调用服务数据，交给HA执行。于是使用nodered初步对想法进行了验证，完成了echo、天猫精灵、小度、叮咚、小爱的接入测试。本来想着发布出来，但发现使用成本很高：需要各自部署http服务器、数据库、nodered，还要公网ip。于是乎为了更好的使用体验，只有继续填坑，折腾出了现在这个平台。虽然有点迟，也算交一份2018年学习HA的作业吧。
0.更新
2019.01.30 翻车了，自定义技能因不允许进行智能家居控制无法上线，只能自用了。
1.介绍
技术架构
- 智能音箱技能平台<=(skill对接，json指令)=>ai-home平台<=(mqtt消息，service指令)=>Home Assistant
特点
- 无需公网ip
- 多种智能音箱统一接入，只需维护一份设备信息
- 基于service指令控制，ai-home平台将语音指令转换成HA的service指令进行控制，更加灵活，例如通过语音调用自动化也是可以的
- 更低的权限要求，不用开放HA全部api权限，可设置控制设备白名单，仅处理白名单设备的控制指令
2.完成度
控制指令
- 目前控制指暂时只有开/关操作
支持平台
- alexa：已对接测试，提交技能审核
- 天猫精灵：已对接测试，提交技能审核
- 小度：已对接测试，提交技能审核
- 叮咚：已对接测试，提交技能审核
- 小爱：认证需要搞手持身份证，放弃
- 有其它音箱接入需求可以反馈我研究下
问题
- 多用户使用场景没有条件测试，估计有不少bug
- 多用户并发下服务器处理性能、带宽问题
3.隐私政策
保存数据内容
- 需要保存用户名以及相应的设备信息
多用户安全性保障
- mqtt启用TLS
- acl来隔离不同用户的主题
- 对mqtt消息进行加密
服务不可用可能性申明
- 不可抗力自然因素
- 断电、断网
- 服务器宕机
- 本人偷懒
综上所述，本接入方法仅当测试和学习使用，不建议录太多的设备使用。
4.使用说明
- 设备名称（中文）：语音指令用，指定控制的设备
- 设备名称（英文）：echo音箱用
- 位置：语音指令用，指定设备的位置
- 设备类型：暂时没用
- 设备ID：HA中设备的entity_id，如果服务不需要，可以随便填
- 控制指令类型：暂时只有打开、关闭，选中后需要继续填写指令内容
- 指令内容：填写语音指令对应的对应的HA service指令，格式为：’HA服务全称[键值对1][键值对2]’，如果要追加其他service数据，增加方括号[]填写键值对即可。
1
2
3
4
5
6#样例：switch.turn_on[a:1][b:2]，最终HA收到服务数据为
{
"entity_id":"switch.test",
"a":"1",
"b":"2"
}注意
键值对的值目前只支持字符串。
- icon（图标）：展示的图标，设备管理页面显示
HA配置
参见github
技能调用
技能调用名称为“家庭助手”（暂定），一般有两种方式调用：
- 待机状态下，先唤醒：“xxxx（音箱唤醒词），打开家庭助手”，然后说“打开主卧的灯”
使用建议
天猫精灵不能这样用，会调用自己的智能家居技能。
- 待机状态下，直接：“xxxx（音箱唤醒词），让家庭助手打开主卧的灯”
补充
具体有待正式测试确认。
- 控制指令说明
- 打开/关闭
1
2
3
4
5#打开/关闭
#用途：一般为电源控制
#语义：{操作}{房间名}的{设备名}
#例子：打开主卧的灯。
#备注：{操作}、{房间名}为枚举，{设备名}自定义5.遇到的坑
- 各音箱平台指令的解析
- 设备管理页面前端技术Vue、jQuery WeUI
- 多用户场景下mqtt消息发送、处理
- HA中为不影响原有mqtt功能新起mqtt实例
- 安全性保障
- 搭建服务器系统环境、网络环境
6.Thanks To
- qebabe@瀚思彼岸 for 设备管理页面参考
- try-to@github for 接入平台端mqtt功能
- mqtt组件@Home-assistant for HA端mqtt功能
