文章目录
1 AWS IOT接入模型
1.1 AWS shadow 使用模型
1.2 APP作为IOT Device接入
1.3 Server作为IOT device接入

1 AWS IOT接入模型

1.1 AWS shadow 使用模型

image.png

APP 通过HTTP 更新AWS Thing shadow属性控制Device ,当Device 更新完相关属性对应操作后会response AWS IOT Cloud 更新对应AWS Thing shadow中属性。 APP 通过http 轮询去查询Thing Shadow更新状态是否成功。

该方式通信单向，即APP 可以看通过AWS IOT操作Device，但Device操作成功后只能更新Shadow状态，而APP需要轮询查询shadow状态来判断是否更新成功，不能由Device直接操作APP。此操作方式为AWS 官方建议方式。

1.2 APP作为IOT Device接入

image.png

APP和Device 均作为DEVICE IOT DEVICE进入AWS IOT Cloud，两者直接通过自定消息协议，使Device 订阅APP的消息，APP订阅Device定义的消息。两者直接相互订阅MQTT消息实现相互通信，这种方式通向双向，可以实现双向Event这种效果。但是这样会增加IOT设备数量及请求增加AWS IOT费用开销。

1.3 Server作为IOT device接入

image.png

但我们需要对权限作为较为详细地控制时且又不想把APP去做轮询也不想把APP当做AWS IOT设备接入，则可以通过服务器作为一个AWS IOT设备进入然后监听相应设备Shadow操作成功后响应的Topic，即可得到事物更新后的响应，进而返回给APP等操作结果。这种方式需要监听所有正在操作设备的事件，且同样会增加消息通信资费，但可以通过Event方式获得操作结果而不用去轮询，且也不用担心第二种方案APP 作为IOT设备带来的开销。但这种方案，DEVICE同样无法主动通知到APP,需要采用三方 Push等方案。且AWS IOT 每个Client只支持订阅50个设备，通过AWSIOTDEVICE 设备进仅能同时操作50个设备得到操作结果，大于这种情况应该改将serve与AWS IOT Cloud换成HTTP方式使用类似于第一种方案的轮询来获取结果。

原文链接：https://blog.csdn.net/m0_37263637/article/details/90413537