云云接入开发日记1
云云接入开发日记1
写这篇文章的时候，已经不是开发初期；
已经完成了百度、Alexa、小米的全全对接，并且上了线在使用；
因此本篇是从未来往前看的开发日记[回顾]篇，回顾回顾开发云云接入平台的苦于辣；
有什么用
一个东西的诞生，总能有一个说服所有人的理由，voice-cloud-cloud也不意外；
/**
* https://dueros.baidu.com/didp/doc/dueros-bot-platform/dbp-smart-home/protocol/discovery-message_markdown
*/
BAIDU,
/**
* https://developers.xiaoai.mi.com/documents/Home?type=/api/doc/render_markdown/SkillAccess/skill/CustomSkillsMain
*/
XIAOMI,
/**
* https://developer.huawei.com/consumer/cn/doc/smarthome-Guides/yunaccount-0000001075288087
*/
HUAWEI,
/**
* https://www.aligenie.com/doc/357554/cmhq2c
*/
TMALL,
/**
* https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-discovery.html
*/
ALEXA,
/**
* https://developers.home.google.com/cloud-to-cloud/integration/sync?hl=zh-cn
*/
GOOGLE
以上是目前主流的所有产商的智能语音音响的所有技能开发云云对接的文档，首先在接触百度的时候，也是第一次去设计去了解什么样的架构，才可以去对接这么多平台的协议；
然后小度的入门图直抒胸臆的带来了灵感：
voice-cloud-cloud 的存在的理由：就是 在图中 小度智能家居IOT云 与 开发者IoT云 间架立一个两者的通讯转换的协议；
在简单的说，就是把小度说的，转换成开发者云设备能听的懂的；
最终voice-cloud-cloud确定了他的位置与初步架构：产品转换、模型转换、协议转换...
怎么做的
关于架构，已经有出过一篇文章和系统的简单架构图，在 物联网语音云云接入 中：
作为双向转换的中间层应用，一是开发云将自身云属性翻译为三方云，二是对方云翻译为开发云属性；
这也是这个项目最核心，也是最难搞定的一部分。
因为各类三方云的属性真的囧不相同，有的恶心要命，有的他想你好，但却做了坏的事；
如何去做：核心以表配置为主
即只需要在数据库中配置，我方code 映射 对方code，对方code 映射 我方code，在通过页面方式展现使用；
说起来是不是很轻松，什么一对一，我的开是switch=1 ，你的是trunOn....
最开始对接一个平台的协议时确实是这么想，并且这么去构建的；
随着平台的增加，发现各平台针对设备的一个功能的设置会出现很不同的地方；
还是以开关举例，我方云是 switch 属性，value为0时关，为1时开。
有些云中，开是 turnOn ，关是 turn off 没有值。
再比如，Alexa中的范围控制器与模式控制器两个动作，会对应到 我方云的多个code上。
....
在对接他们的同时，实际也是与这些code，围绕着一对一，一对多，多对一苦苦伤脑筋，可能语义上无法形容这个的痛苦。
举个生动的例子：
你有6个女朋友，周一到周六每个分配一天，在周日时一起过；
这一天一起吃饭，A希望你喂它，B希望你喂它........F吃醋了直接离场
除了映射属性的设计外，还有技能、产品类型、技能语义配置等等；
有的是在后续平台中增强实现的，不过都还好，因为只是产品属性的一部分；
授权认证
再而则是技能应用的授权这块，所有的平台都要求以Oauth2服务器模式进行token授权和刷新的。
其中只有Alexa与其余的平台有差异，Alexa需要通过LAW应用进行一个它的同步两次请求的授权
其他的平台统一都是两个接口+一个刷新动作的认证方式：
- 获取应用授权码接口，入参为客户端id
- 技能请求授权令牌，入参为授权码
- 刷新动作，在每次接收到三方平台请求时刷新令牌时间，或者定时刷新
有什么坑
重点想吐槽的就是对接时遇到的大大小小坑；
首先说 Alexa 因为他是自测时的重灾区；
首先是他的测试响应，无
就是无，他没有任何的错误编码，提示等等，只要你的技能响应有一点不如他意，就会请求失败；
在测试中，首先是授权后的发现设备：
这里就是第一个点设备名，不能有中文；
虽然是海外的应用，但是中文名字这一点不支持的话，至少也要在文档中体现出不支持语言把，后续就是一点一点排除，直到发现名字不为中文时发现成功；
然后就是 cookie的设置，因为其他平台的cookie设置都是非常自由的一个字符串，在Alexa中必须为key-value对的对象，即Map或JSONObject；
发现设备之后是控制设备，因为事前设计比较好，所以值映射与值的函数转化等等都可以一次通过，那控制设备也一次就成功，我是这样想到；
但是Alexa方一直提醒设备没有响应，我就一直找一直找，终于发现了。
控制请求的响应体中的时间：
竟然是yyyy-MM-dd'T'HH:mm:ss'.'SS'Z'，中间有一个 . 末尾一个 Z ，我因为少了这个点，Alexa一直解析失败然后报错，但又不给任何提示TAT。
控制请求后查询设备；
这里让我了解到了，原来灯设置的色温和颜色原来是两选一的！
在Alexa中这个设备有什么功能，在Alexa App 上界面中有的功能还不是通过配置他的属性他的技能体现的，而是取决于设置这个产品是什么类型；
即空调：设置温度，模式。
窗帘： 全开，全关。
....
这让我一度怀疑是不是我的代码有问题，怎么在APP上看不到这个设备对应属性的变化。（虽然属性在界面看不到，但是语音控制还是有效）
最后是关于Alexa，Google这两海外平台的特殊之处：语义定义；
这一点我能理解，即自定义设置说什么话可以控制什么属性，可以非常方便开发者云对接时的遍历；
但是你Y的也太难配置了，有@type 为key这一灾难的字符串就罢，一个功能属性值的深度，广度都太难把握了；
以至于发现设备时，Alexa提示失败，然后还不存在原因显示，就这么一点点的去排查......
不过好在Alexa是在对接完其他平台之后，最后对接的三方云；
这里就要说一点体外话了，到底是百度抄了Alexa还是....，总之在很多细节的处理上和国内的众多平台一致，难点还是在于Alexa测试时强制要求我们按照文档案例的格式返回，否则报错，还没有提示；
总结
因为最近的Alexa留下的坑印象太深，执念太重，所以其余平台留着后续与页面开发日记一起；
还没有说我为什么要开发这个平台：
当我去接入百度的时候，网上没有轮子可以使用，我很痛苦
当我接入小米的时候，论讨也没有资料讨论，我更痛苦
就像以下的这篇诗
他们追杀共产主义者的时候， 我没有说话———因为我不是共产主义者； 他们追杀犹太人的时候， 我没有说话———因为我不是犹太人； 他们追杀工会成员的时候， 我没有说话———因为我不是工会成员； 他们追杀天主教徒的时候， 我没有说话———因为我是新教教徒； 最后他们奔我而来， 已经没有人能为我说话了。 ——马丁·尼莫拉牧师
感觉非常有必要做一个全平台云云接入的通用平台，哪怕是为了我，或者可以帮助到有可能看见的人