去年买了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功能