? ? ? ? 此项目是TP-LINK公司所属的一个项目，在此只做技术分享，不为任务商业用途。IFTTT 在全球 IoT 生态中占有一席之地，囊括了众多同类竞品的设备，可帮助用户实现跨品牌多设备之间的联动控制。根据 Action、Query 和 Trigger 业务场景设计，TP-LINK公司的Tapo 设备如 Tapo Plug 和 Tapo Bulb 需要支持在 IFTTT 创建规则的情况下被连接和控制，同时 IFTTT 也需要接收来自 Tapo 设备的事件。所以此次项目实现 IFTTT-Iot Adapter 服务，提供接口供 IFTTT 调用，内部对接 IoT-App Server，实现负责 IFTTT 和 IoT-App Server 之间消息的协议转换和转发。

1.2 任务概述

????????新增一个 IFTTT-IOT Adapter 服务，支持配置开发 IFTTT service，具备新增如下功能：提供 Action 、Query 和 Trigger 接口供 IFTTT 调用；根据服务名分发请求到具体的服务；各个服务实现协议转换，调用自己的云端服务，如 Tapo 通过 gRPC 客户端调用 IoT[1]App Server 服务；新增处理设备状态更改事件的 kafka 消费者任务，消费事件，调用 IFTTT 的 http 实时接口进行通知；对接 soho poller（事件分发模块），接收账号注销请求，清理用户数据。

????????开发前需要仔细阅读官方开发文档，根据开发文档的指引和规范，设计好自己要实现的服务，明确接口的请求必要参数和相应数据格式以及请求流程。Ifttt要求开发者的服务暴露的接口需要满足开发文档的要求，主要有三类接口，分别是Action、Query和Trigger，另外都有其对应的field接口即获取字段属性。不同类型的请求接口有不同的请求参数和相应数据格式的要求。另外服务需要支持ifttt系统测试用例，要求服务实现一个testsetup接口完成测试准备工作并返回测试数据，服务内部需要区别测试模型下的请求并做对应的处理。服务在产生事件并需要上报的时候，调用ifttt的实时通知接口https://realtime.ifttt.com/v1/notifications?，之后ifttt会调用trigger获取事件消息。具体细节请查阅官方文档?Service API requirements - IFTTT。开发完服务并部署之后就可以在ifttt网站上创建service，完善必要的文案信息和接口细节，通过系统的自带测试用例过后，便可以创建小程序进行If This Then That的测试了。

? ? ? ?此项目使用springboot技术开发。

1.3 术语定义

术语定义
IFTTT	即 IF this THEN that，国外一款软件，支持创建一些规则来控制设备
IFTTT-Iot Adapter	即将开发的新模块，IFTTT 与 IOT 云通讯的中间模块，接收 IFTTT 的请求
IoT-App Server	IoT 云服务，为 Tapo 下的 IoT 等设备提供后端支持
Tapo	TP-LINK 下的一个 IoT 产品系列
Tapo Bulb	Tapo 品牌下的智能插座
Tapo Plug	Tapo 品牌下的智能插座
Action	IFTTT 发送数据给设备，或者是在设备上创建资源，如开/关设备等
Query	IFTTT 一个查询方式，获取设备信息，如查询设备开关状态等
Trigger	IFTTT 获取设备上的事件，如设备开关状态变化、颜色变化等

2 需求分析
?

需求
设备/场景	Trigger	Query	Action
Bulb	Device turned （on/off） Bulb color changed	Device Status （on/off） Current bulb/light color	Device turned （on/off） Change brightness Change color Change color temperature
Plug	Device turned （on/off）	Device Status （on/off）	Device turned （on/off）

3 原理概述

????????由于 IFTTT 可以对接多个不同的服务，计划在实现的 IFTTT-Iot Adapter 中增加支持多个服务的功能，与 IFTTT 对接的接口将请求根据服务名称分发到具体的服务，各个服务再根据自己的业务具体处理 Action、Query、Trigger 的请求；各个服务实现自己的事件上报接口，一旦有事件上报，实时通知 IFTTT。

3.1 协议分析

? ? ? ? 1、对第三方平台IFTTT 提供接口：HTTPS 协议；

????????2、内部调用 IoT-App Server 接口： gRPC 协议；

????????3、服务之间异步调用：通过 kafka，在 Trigger 场景下是 iot-subsubscription 给 IFTTT-Iot ????????Adapter 发送异步消息。

4. 系统架构描述

4.1 架构设计

总体完成功能：

1. IFTTT-Iot Adapter 与周边服务构成总体系统结构图如上，IFTTT 发起 Action、Query 和 Trigger 请求，IFTTT-Iot Adapter 接收之后内部对请求做协议转换，通过 gRPC 请求调用 IoT-App Server 接口查询、控制设备（不包括在基础云维持长连接的旧固件的 Tapo Plug）；

2. 设备端通过短连接的方式上报设备影子数据更改事件到二级订阅，二级订阅将事件写入 iot.ifttt.event.v2 主题队列，IFTTT-Iot Adapter 的消费者程序从中消费，调用 IFTTT 实时通知接口。

4.2 模块结构

IFTTT-Iot Adapter 的实现如下结构图，主要分成 Controller、Service、Dao、gRPC api 和 Consumer 几个模块：

4.3 接口流程图

????????IFTTT 调用 Actions 和 Queries 请求的流程：

????????IFTTT 调用 Trigger 请求的流程：

5.?任务（或进程/线程）设计

????????IFTTT-IOT Adapter 需要新增 kafka 消费者任务，持续消费来自主题 iot.ifttt.event.v2 的消息。

5.1 原理

????????IFTTT Adapter 需要接收 Tapo Plug 和 Tapo Bulb 的设备事件，二级订阅通过将设备上报的事件消息写入特定主题队列来转发消息。

5.2 流程设计

????????IFTTT Adapter 内部 kafka 消费者线程处理流程:

?说明：

1、步骤 6 实时通知的时候可以传 trigger_identity，可以区分一个 tilinkid 被多个 ifttt 用户账号使用的场景；如果调用超时，重试一次；

2、步骤 5 获取事件消息之后，根据 reportedChangedPropList 字段判断更改的属性，然后根据 trigger 类型和用户 id 获取 trigger 信息，再包装 trigger event 数据，写入数据库写入的时候判断 trigger event 的数量是否超过 trigger event 的最大数量，是的话删除存储时间最久的一条数据，再写入；

3、步骤 4 根据用户 trigger 配置过滤的时候先过滤对应 trigger 的，再按用户（包括 Owner 用户和分享用户）过滤。?