+
+ | 参数 |
+ 类型 |
+ 说明 |
+
+
+ | method |
+ String |
+ event_post 表示事件上报。 |
+
+
+ | clientToken |
+ String |
+ 消息 ID，回复的消息将会返回该数据, 用于请求响应消息的对比。 |
+
+
+ | version |
+ String |
+ 协议版本，默认为1.0。 |
+
+
+ | eventId |
+ String |
+ 事件的 ID，在数据模板事件中定义。 |
+
+
+ | params |
+ String |
+ 事件的参数，在数据模板事件中定义。 |
+
+
+ | timestamp |
+ Integer |
+ 事件上报的时间，不填写该字段表示就使用事件上报本身的时间。 |
+
+
+ | type |
+ String |
+ 事件类型，info 为信息，alert 为告警，fault 为故障。 |
+
+
+
+组合出向上行请求发送的AT命令如下：
+```c
+AT+TCMQTTPUB="$thing/up/event/FWR8PGACUS/ESP8266_Dev_001",0,"{ \"method\":\"event_post\"\, \"clientToken\":\"123\"\, \"version\":\"1.0\"\, \"eventId\":\"low_voltage\"\, \"type\":\"alert \"\, \"params\": { \"voltage\":2.8 } }"
+```
+返回结果如下，上报成功：
+```
+OK
++TCMQTTPUB:OK
+```
+同时收到平台发给设备的回应：
+```
++TCMQTTRCVPUB:"$thing/down/event/FWR8PGACUS/ESP8266_Dev_001",75,"{"method":"event_reply","clientToken":"123","code":0,"status":"","data":{}}"
+```
+其中的json数据整理一下如下：
+```c
+{
+ "method":"event_reply",
+ "clientToken":"123",
+ "code":0,
+ "status":"",
+ "data":{}
+}
+```
+在云端设备事件日志中可以看到：
+
+
+### 3.4.5. 设备行为调用
+当应用通过云端向设备发起某个行为调用时，开发平台为设备行为的处理设定了默认的 Topic 如下：
+
+ - 应用调用设备行为 Topic： `$thing/down/action/{ProductID}/{DeviceName}`
+ - 设备响应行为执行结果 Topic： `$thing/up/action/{ProductID}/{DeviceName}`
+
+首先订阅设备应用调用设备行为的Topic：
+```c
+AT+TCMQTTSUB="$thing/down/action/FWR8PGACUS/ESP8266_Dev_001",0
+```
+返回结果如下：
+```
+OK
++TCMQTTSUB:OK
+```
+智能灯默认数据模板中没有……需要手动创建，新建一个行为功能：
+
+新建之后在自定义功能这一栏即可看到：
+
+进入设备在线调试界面，发送行为：
+
+在串口助手中可以看到模组接收到云端的消息：
+```c
++TCMQTTRCVPUB:"$thing/down/action/FWR8PGACUS/ESP8266_Dev_001",132,"{"method":"action","clientToken":"1d603a84c71e4d1da38c2dacce27112e","actionId":"blink","timestamp":1593396804,"params":{"period":5}}"
+```
+整理一下json格式如下：
+```json
+{
+ "method":"action",
+ "clientToken":"1d603a84c71e4d1da38c2dacce27112e",
+ "actionId":"blink",
+ "timestamp":1593396804,
+ "params":
+ {
+ "period":5
+ }
+}
+```
+在串口助手中向设备响应行为执行结果 Topic回复响应，响应内容格式如下：
+```json
+{
+ "method": "action_reply",
+ "clientToken": "1d603a84c71e4d1da38c2dacce27112e",
+ "code": 0,
+ "status": "success",
+ "response": {
+ "Code": 0
+ }
+}
+```
+组合出发送响应的AT指令如下;
+```c
+AT+TCMQTTPUB="$thing/up/action/FWR8PGACUS/ESP8266_Dev_001",0,"{ \"method\": \"action_reply\"\, \"clientToken\": \"1d603a84c71e4d1da38c2dacce27112e\"\, \"code\": 0\, \"status\": \"success\"\, \"response\": { \"Code\": 0 } }"
+```
+返回结果为：
+```
+OK
++TCMQTTPUB:OK
+```
+至此，使用ESP8266腾讯云定制固件对接腾讯云IoT Explorer平台的测试完成。
diff --git a/doc/25.How_To_Use_Esp8266_Tencent_Firamware_Connect_Iot_Hub.md b/doc/25.How_To_Use_Esp8266_Tencent_Firamware_Connect_Iot_Hub.md
new file mode 100644
index 00000000..446539cb
--- /dev/null
+++ b/doc/25.How_To_Use_Esp8266_Tencent_Firamware_Connect_Iot_Hub.md
@@ -0,0 +1,248 @@
+# 1. 腾讯云ESP8266定制固件说明及烧录
+
+腾讯云IoT AT指令是一套针对使用通讯模组（2G/4G/NB/WIFI）接入腾讯云物联平台的定制AT指令集，如果通讯模组实现了该指令集，则设备接入和通讯更为简单，所需代码量更少。 ESP8266作为IoT领域使用最广泛的一款WiFi芯片/模组，我们在其通用AT指令基础上，增加了腾讯云IoT AT指令集，形成一个定制的模组固件QCloud_IoT_AT_ESP8266，腾讯云IoT定制的AT模组固件QCloud_IoT_AT_ESP8266，适用于所有FLASH大小为2MB或者2MB以上的ESP8266模组。
+
+固件烧录方法请阅读文档：[腾讯云 IoT AT ESP8266 定制固件及说明](https://github.com/tencentyun/qcloud-iot-esp-wifi)。
+
+# 2. 云端配置
+登录腾讯云, 搜索"云产品"下的"物联网通信"产品, 或直接访问：
+
+[https://console.cloud.tencent.com/iotcloud](https://console.cloud.tencent.com/iotcloud)
+
+
+
+## 2.1. 创建新产品
+
+> 对于认证方式, 指定了设备通过何种方式和云端进行双向认证. 默认的证书方式相对于密钥认证安全性高一点, 但是问题在于证书方式需要在嵌入式设备端存储证书同时实现证书的相关处理, 对设备的RAM和ROM要求较高, 相对而言, 密钥认证的方式资源占用量就小点, 由于我们主要支持的设备都是小型嵌入式设备, 因此选用密钥认证。
+
+> 数据格式指的是设备和云端进行数据交互时候使用的格式, json格式为文本字符串, 可读性高, 并且便于解析, 对于功能复杂的设备交互而已比较理想, 但是对于小型设备或是定制设备, 数据单一, 或是有自定义的格式(二进制或是文本), 这种时候, 用自定义的数据格式, 一方面节约流量, 另一方面比较灵活.。
+
+创建成功后，获取到产品ID：
+
+
+## 2.2. 创建新设备
+
+
+添加完设备后, 会告知设备对应的密钥. 该密钥将会用于之后设备与平台通信时的认证：
+
+为了实现设备间的通信, 我们还需要创建第二个设备, 操作同上, 将其命名为"dev2"：
+
+
+## 2.3. 设置Topic
+可以在"权限列表"中看到Topic对应的操作权限：
+
+
+平台默认配置了三类的Topic, 用于执行发布和订阅.，这里之所以**是三类而不是三个**, 是因为Topic里使用了变量.。
+
+- `WDRRDCF1TE`实际上是productID；
+- `${deviceName}`为平台设置的变量, 即设备名；
+- `control`和`data`以及`event`为Topic名字.；
+
+所以, 在我们创建了2个设备dev1和dev2的情况下, 在 BearPiTest 产品下, 即存在6个Topic, 分别为:
+
+- WDRRDCF1T/dev1/control 订阅权限
+- WDRRDCF1T/dev1/data 发布和订阅权限
+- WDRRDCF1T/dev1/event 发布权限
+- WDRRDCF1T/dev2/control 订阅权限
+- WDRRDCF1T/dev2/data 发布和订阅权限
+- WDRRDCF1T/dev2/event 发布权限
+
+这里默认的Topic已经足够我们使用, 不需要额外添加Topic和权限了。
+
+## 2.4. 设置规则引擎
+规则引擎本身不属于MQTT协议的范畴, 但是平台侧出于安全角度考虑添加了规则引擎, 实现了Topic之间的转发操作, 我们需要合理的设置规则引擎才能实现多个设备之间的数据收发, 由于理解起来比较复杂, 我们这里简要讲解下为什么需要规则引擎, 规则引擎的作用, 如何设置规则引擎.
+
+1. 为什么需要规则引擎
+
+ 在上节的Topic中, 我们知道, 在平台侧, 对于不同的Topic, 规定了不同的权限, 例如, 对于`WDRRDCF1T/dev1/event`这个Topic, 只具有发布权限, 而对于`WDRRDCF1T/dev1/control`这个Topic, 只具有订阅权限. 对于设备dev1, 很自然的, 会朝`WDRRDCF1T/dev1/event`这个Topic发送数据, 并且订阅`WDRRDCF1T/dev1/control`这个Topic的消息. 但是这里就会涉及到, event的数据最后到哪去, control的数据从哪里来的问题.
+
+ 在本文的例子中, 我们希望dev1和dev2发生交互, 即相互收发消息. 由于MQTT是基于Topic的发布订阅机制, 因此, dev1想要获得dev2的数据, 直觉上, 需要订阅dev2发布消息的那个Topic. 假定dev2朝`25KCIUIR1G/dev2/event`Topic上发送数据, 那么dev1想要获得dev2发布的消息, 最直接的办法是订阅同样的Topic, 即`25KCIUIR1G/dev2/event`, 但是这里存在几个问题, 首先, event Topic只具有发布权限, 没有订阅权限, 其次, **在平台侧, 规定了, 不允许跨设备发布或是订阅Topic**, 也就是说, 对于dev1, 只能看到或只允许访问`WDRRDCF1T/dev1`这个Topic以及其下属的Topic, 不能访问`WDRRDCF1T/dev2`及其下属Topic.
+
+ > 平台侧添加不允许跨设备访问Topic的规则虽然不直观, 但却是合理的. 如果不添加这条限制, 那么一个设备可以不加限制的订阅同一个产品下所有其他设备的Topic, 获取其上报的消息, 这存在潜在的安全漏洞.
+
+2. 规则引擎的作用
+
+ 因为不允许直接跨设备访问Topic, 所以需要依靠"规则引擎"来手动添加规则, 将指定的Topic消息转发到另一个Topic上, 实现不同设备之间的通信.
+
+
+
+ 上图介绍了规则引擎的主要作用"republish", 即将一个Topic下的消息republish到另一个Topic下. 从图中我们可以看到, 规则引擎将`WDRRDCF1TE/dev2/event`的消息republish到了`WDRRDCF1TE/dev1/control`下. 将`WDRRDCF1TE/dev1/event`的消息republish到了`WDRRDCF1TE/dev2/control`下。
+
+ 这样, 对于dev1而言, 只需要订阅`WDRRDCF1TE/dev1/control`就可以接收来自`25KCIUIR1G/dev2/event`的消息了，dev2同理。
+
+3. 设置规则引擎
+
+ 在物联网通信界面选择"规则引擎"--"新建规则", 随意指定一个规则名称, 我们这里不妨设置为"1to2"：
+
+
+
+这里, 我们看到规则的详细设置信息, 主要包括"筛选数据"和"行为操作"。
+
+"筛选数据"针对指定Topic接收到的消息内容进行进一步的筛选, 比如匹配消息中的字段来决定是否执行之后的设置的"行为操作".，而"行为操作"则是指定对通过匹配的消息进行何种操作, 主要的操作有"数据转发到另一个Topic(Republish)", "转发到第三方服务(Forward)"以及转发到腾讯云各个对应组件中。
+
+
+
+ 上图是设置好的规则, 这里, 我们将"筛选数据"部分的筛选字段设置为`*`, 筛选的Topic为`WDRRDCF1T/dev1/event`, 条件设置为空, 即不筛选数据, 全部匹配，然后, 执行的操作是将数据转发到`WDRRDCF1T/dev2/control`, 设置完这条规则, 就实现了dev2通过订阅control就能收到dev1发送到event的数据。
+
+ > 关于"筛选数据"的设定：
+ >
+ > 由于我们在新建产品, 设置数据格式的时候选择了自定义数据格式, 在自定义数据格式的情况下, 当前平台将其当做二进制流来处理, 也就无法通过匹配字段进行数据筛选.
+ >
+ > 如果在进行产品的时候, 使用数据格式是json, 那么此处就可以根据json中的字段进行SQL的匹配和筛选.
+
+ 同理, 我们再设置新的一个规则"2to1", 实现`WDRRDCF1T/dev2/event`到`WDRRDCF1T/dev1/control`的转发：
+
+
+ 规则引擎都设置好后，记得点启用按钮，这样, 在平台侧dev1到dev2的双向数据通路就打通了：
+
+
+## 2.5. 云日志
+在平台侧都设置好后, 我们在之后的测试过程或是通信过程中, 往往还需要查看平台是否收到了设备发送上来的消息, 对消息执行了哪些操作, 消息的具体内容(payload)是什么. 腾讯云提供了物联网通信产品的"云日志"功能和腾讯云组件"消息队列CMQ"。
+
+
+
+日志中可以看到日志记录了设备的连接, 连接断开, 发布, 订阅等行为, 也记录了规则引擎的操作, 还有CMQ队列的一些行为日志.。
+
+## 2.6. 消息队列CMQ
+可以在产品列表中找到"消息队列"选项, 设置队列所想要接收的消息类型后保存配置, 即可将平台侧收到的设备消息额外发送到腾讯云消息队列CMQ组件中：
+
+> 在密钥认证下, 消息的内容(payload)是经过base64编码的, 所以在平台侧看到的数据类似乱码实际上是经过编码后的结果, 想要查看具体的内容, 可以在linux下, `echo