阿里IoT使用总结 - alcoholdi的专栏 - CSDN博客
首先得感慨下写个App比之前真的简单方便多了。
需要推送功能直接考虑集成友盟、极光、个推、小米推送、华为推送。
需要IM功能直接考虑集成环信、融云、网易云信、腾讯云通、阿里云川等这些解决方案。
这些传统功能就不谈了,连这两年崛起的直播、娃娃机、答题业务,你都能找到好几家第三方解决方案,提供完整sdk直接集成。
物联网(英语:Internet of Things,缩写IoT)
理论上推送、即时通讯、物联网在技术层面都是通过xmpp、mqtt、CoAP这些协议建立个长连接从而可以双方互发消息,或者更集中地说是为了如何优雅的解决服务器实时发消息到客户端的问题(因为客户端发消息到服务端只需要Http协议就可以)。那么物联网,或者说以本文的阿里IoT为例,对比起来另外两者有什么区别呢?
我认为最重要的区别就是IoT有一个影子(shadow)的概念。
在亚马逊云里,这样描述的影子的。事物影子服务充当中介,支持设备和应用程序检索和更新事物影子。
阿里云里,是这么描述的。设备影子是一个 JSON 文档,用于存储设备上报状态、应用程序期望状态信息。
因为物联网里面的设备端,并不保证设备端24小时在线的。所以如果想查询设备信息,或者更新设备状态,发个请求过去返回超时回来,一看是设备不在线,是个很麻烦的事。所以设备需要一个缓存机制,当设备不在线时,能让我们①获取他的状态,②保存我们对设备期望状态以便下次设备上线能拿到。
阿里文档给了几个例子可以帮助理解一下: 设备影子介绍
IoT里面是根据『产品』对所有智能设备分类的。比如说智能台灯A是一个产品,智能插座B是另一个产品。每个产品根据productKey来区分。一个产品里面有很多台设备,每个设备都有一个deviceName和deviceSecret与之对应。
通常把这三者联合起来称作 三元组信息(productKey、deviceName及deviceSecret)。
阿里IoT套件支持的两种通信模式,PUB/SUB以及RRPC。RRPC稍后再提,先来讲讲这个PUB/SUB,对应中文发布/订阅的意思。注意区分Topic类和具体的Topic的。
Topic类:/${productKey}/${deviceName}/update
具体的Topic:/${productKey}/device1/update或者/pk/device2/update
阿里给产品默认定义了如下三个Topic类:
/${productKey}/${deviceName}/get:订阅
/${productKey}/${deviceName}/update:发布
/${productKey}/${deviceName}/update/error:发布
还有两个影子相关的的Topic类提供使用:
/shadow/update/${productKey}/${deviceName} (设备或应用程序)更新影子的Topic
/shadow/get/${productKey}/${deviceName} 设备影子会更新状态到该Topic,设备订阅此Topic的消息。
当然可以自己添加更多的Topic类,按照这种格式写一个就行。
对于设备端接入,阿里提供了C-SDK、Java-SDK、Android-SDK和iOS-SDK。
Java-SDK直接是使用开源框架『Eclipse paho mqtt』。而Android-SDK则是阿里对这个开源框架进行了一层封装。
所以搞懂了这个框架怎么用,就能知道MQTT的连接原理。
看了下demo后,我总结为以下步骤。
1.引入eclipse.paho相关的库,库里有MqttClient但是针对Android有更适合MqttAndroidClient提供我们使用。
compile 'org.eclipse.paho:org.eclipse.paho.android.service:1.1.1'
compile 'org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.1.1'
2.建立连接需要三元组信息(productKey、deviceName及deviceSecret)。对于设备板子,提前把这些烧录进去是件很麻烦并且很不灵活的事情。所以一般是设备确定一个自己的唯一标识,比如说MAC地址或者SN。发出一个请求自己的后台服务器,后台帮忙在IoT创建一个设备,并返回相应的三元信息。
3.通过请求『https://iot-auth.cn-shanghai.aliyuncs.com/auth/devicename』的返回字段,能得出最终的长连接Uri(一般为ssl://host:port)、username和password。
4.执行mClient = new MqttAndroidClient(context, serverUri, clientId)
5.设置mqtt的callback,mClient.setCallback( new MqttCallbackExtended(){//实现方法} )。里面需要的方法如下:
5.1 connectComplete表示连接成功。
5.2 connectionLost表示连接失败,会自动尝试重连所以不用管。
5.3 deliveryComplete应该是发送消息成功的返回,可以忽略。
5.4 messageArrived(String topic, MqttMessage message) 接受消息
6.配置MqttConnectOptions参数, 比如Username,password,automaticReconnect,最后执行MqttAndroidClient.connect(options, ...)
7.根据是否连接成功,开始订阅Topics,如/${productKey}/${deviceName}/get 和 /shadow/get/${productKey}/${deviceName}
8.订阅了那些Topic,在前面callback类里的messageArrived方法中就是收到该Topic的消息。调用MqttAndroidClient的publish(String topic, MqttMessage message)方法,能往相应Topic中发送消息。
设备端连接成功后,就可以在IoT管理控制台查看当前设备是否在线,查看设备的影子信息,设置期望值给设备影子这些操作了。
除了在控制台能查看设备信息之外,我们在IoT的管理控制台,开启『配置服务端订阅功能』,勾选『设备上报消息』和『设备状态变化通知』(就是设备上下线消息),就能把这些消息推送到阿里的MNS消息队列里面。然后让我们自己的后台服务器订阅这个消息队列,就能实时获取到设备的当前在线状态和其功能状态(比如智能灯有没打开,智能插座有没通电)。
具体来说就是通过和阿里云账号绑定的AccessKeyId和AccessKeySecret,还有写代码通过队列名字比如『aliyun-iot-4CbI0012osF』获取到队列消息。
云端请求设备端(RRPC)
MQTT是使用于发布/订阅的的异步通信模式,但是有时候我们需要发送一个请求到设备端并希望他立刻响应返回。所以阿里为此在MQTT协议的基础上,封装了一套机制专门用于处理同步请求消息。具体来说就是
请求来的Topic会是:/sys/${productKey}/${deviceName}/rrpc/request/${messageId}
设备需要订阅/sys/${productKey}/${deviceName}/rrpc/request/+
设备需要响应回去的Topic是:/sys/${productKey}/${deviceName}/rrpc/response/${messageId}
按照这种格式接受响应和回复,就能实现同步的返回。
参考链接:
M2M 分为处理数据(筛选出哪些需要转发的) 和 转发数据
想要手机控制一盏智能灯的开关,一般的做法就是手机发送一个Http请求到自己的后台服务器,后台服务器再发送命令到阿里IoT,IoT就会通知到智能灯设备打开关闭。
但是这样的做法会让我们服务器的压力过大,所以阿里为此推出了M2M这个解决方案。意思就是通过SQL的语法从某一个Topic里面筛选出想要的数据,像一个拦截器一样。然后转发到另一个Topic里面。这样我们就可以设计成,筛选出手机端发送到IoT的请求,判断出如果是打开关闭智能灯的请求,就把它转发到对应那个智能灯设备里。从而减少自己服务器的压力。
除此之外,阿里IoT其实提供了更多的转发操作。例如转发到Table Store、RDS、Message Queue、DataHub,能让我们更好的完成数据存储,转发,分析等操作。