叮咚音箱对接遇到的问题

叮咚音箱对接的方式和其他智能音箱大同小异,叮咚的云服务器,会把解析过后的结构化数据发送到我们自己的服务器,然后由我们的服务器去做逻辑处理,并将结果返回给叮咚音箱服务器,由音箱返回给用户。

image

但在将叮咚音箱接入到智能家居和智慧酒店的方案中,遇到些问题,在这里记录下来供大家参考。

语义文法的编辑比较复杂

语义文法的作用是让音箱将自然语言转换为程序可以处理的结构化数据。相比天猫精灵、小爱同学通过Web界面配置语义文法,叮咚音箱需要自行通过代码来编写科大讯飞语义开放平台的abnf文法。这种方式带来了非常强大的灵活性,但是对开发者来说,需要额外的学习成本来了解如何去解析自然语言,同时,在非专业系统的学习下写出的文法,未必会比Web界面配置出来的要好用。同时对于叮咚音箱本身来说,将来如果叮咚音箱要使用其他的语义平台,对于开发者来说可能要同时学习多种平台的文法编辑,或者能够将现有的abnf文法转换成其他平台的文法。

语音识别

在实际语音测试中,叮咚音箱多次出现了唤醒后不响应指令的情况,而且根据对接交流群里的反馈,这样的问题不只是我这边出现了,这说明在音箱的使用中还存在一些问题。出现这种情况,对于家庭和酒店的场景,可不能算“智能”。

叮咚服务器不会传设备id

根据叮咚音箱对接文档,目前用于识别的字段仅有user,叮咚服务器并不会将设备的id发送过来。这是最后让我放弃将叮咚音箱接入智能设备的最主要原因,对于智能家居来说,对于智能家居来说,一个用户(user)买了多个智能音箱的情况,比较理想的交互是根据接收语音的音箱的不同执行不同的动作,举例来说,客厅和卧室各有一个叮咚音箱,当用户在客厅说开灯,会打开客厅灯,而在卧室说开灯,则会打开卧室灯。这需要在我们的程序内部,将音箱的id和智能家居后台的room绑定。基于目前的对接文档,对于多个叮咚音箱的家庭,我们也需要在控制语句中把房间包含进去,如“请打开客厅的灯”这样。
在智能家居中,尚可以通过指令中包含到具体房间来实现,在酒店项目中,我们是不可能让住客通过“请打开601房间的卫生间灯”这样的指令来控制的。在智慧酒店中,要通过叮咚音箱来实现控制酒店客房内的设备,只能通过注册多个账号来把user和酒店后台的room绑定。但这样的代价太大了(每个叮咚账号都需要通过手机号来注册,对于几百个房间的大酒店,管理这些账号是非常头疼的)

总结

综合来说,目前叮咚音箱并不适合智能控制类的项目使用,从厂家的主推方向来说,智慧酒店类的更适合天猫精灵(阿里旗下有未来酒店,已经和国内多个酒店客房控制系统厂家合作),智能家居类的项目更适合小爱同学(小米的智能产品本来就偏向家用)。但正如网上所言,语音识别已经达到了97%的准确率,但是为了修正3%的识别差异,用户需要花费更多的时间。智能音箱真正成为智能家居的入口,还有很多路要走,期待有一天,能够出现和人类顺畅交流的“真AI”智慧管家,为人类服务。

(完)

坚持原创技术分享,您的支持将鼓励我继续创作!