Use ESP8266 Tencent Cloud custom firmware to connect to Tencent Cloud platform IoThub

Hits: 0

1. [Tencent Cloud] [ESP8266] custom firmware burning

2. Cloud configuration

Log in to [Tencent Cloud] , search for “Internet of Things Communication” products under “Cloud Products”, or visit directly:


2.1. Create a new product

For the authentication method, it specifies the method through which the device performs two-way authentication with the cloud. The default certificate method is more secure than key authentication, but the problem is that the certificate method needs to store the certificate on the [embedded] device and implement the related processing of the certificate. , The RAM and ROM requirements of the device are relatively high. Relatively speaking, the resource occupancy of the key authentication method is smaller. Since the devices we mainly support are small embedded devices, key authentication is selected.

The data format refers to the format used when the device and the cloud interact with data. The json format is a text string, which is highly readable and easy to parse. It is ideal for device interaction with complex functions, but it is suitable for small devices or customized devices. , the data is single, or there is a custom format (binary or text).

After the creation is successful, get the product ID:

2.2. Create a new device

After the device is added, the corresponding key of the device will be notified. This key will be used for authentication when the device communicates with the platform:
in order to realize the communication between devices, we also need to create a second device, operate the same as above, and add it Name it “dev2”:

2.3. Setting Topic

You can see the operation permissions corresponding to the Topic in the “Permission List”:

The platform is configured with three types of topics by default, which are used for publishing and subscribing. The reason why there are three types here instead of three is because variables are used in topics.

  • WDRRDCF1TEis actually productID;
  • ${deviceName}The variable set for the platform, that is, the device name;
  • controland is datathe eventTopic name.;

Therefore, in the case that we have created 2 devices dev1 and dev2, under the BearPiTest product, there are 6 topics, namely:

  • WDRRDCF1T/dev1/control subscription permission
  • WDRRDCF1T/dev1/data publish and subscribe permissions
  • WDRRDCF1T/dev1/event publish permission
  • WDRRDCF1T/dev2/control subscription permission
  • WDRRDCF1T/dev2/data publish and subscribe permissions
  • WDRRDCF1T/dev2/event publish permission

The default topic here is enough for us to use, no need to add additional topics and permissions.

2.4. Setting up the rule engine

The rule engine itself does not belong to the scope of the MQTT protocol, but the platform side adds a rule engine from a security perspective to realize the forwarding operation between topics. We need to set a reasonable rule engine to achieve data sending and receiving between multiple devices. Since it is more complicated to understand, here we briefly explain why the rule engine is needed, the role of the rule engine, and how to set the rule engine.

  1. Why do you need a rules engine

    In the Topic in the previous section, we know that on the platform side, different permissions are specified for different topics. For example, for WDRRDCF1T/dev1/eventthis topic, only publish permission, and for WDRRDCF1T/dev1/controlthis topic, only subscription permission. For device dev1, It is natural to WDRRDCF1T/dev1/eventsend data to this topic and subscribe to WDRRDCF1T/dev1/controlthe messages of this topic. But here it will involve the question of where the event data goes and where the control data comes from.

    In the example in this article, we want dev1 and dev2 to interact, that is, to send and receive messages to each other. Since MQTT is a Topic-based publish-subscribe mechanism, dev1 wants to obtain the data of dev2. Intuitively, it needs to subscribe to the Topic where dev2 publishes messages. . Assuming that dev2 25KCIUIR1G/dev2/eventsends data to the Topic, the most direct way for dev1 to get the messages published by dev2 is to subscribe to the same Topic, that is 25KCIUIR1G/dev2/event, but there are several problems here. First, the event Topic only has the permission to publish, not the permission to subscribe , Secondly, on the platform side, it is stipulated that it is not allowed to publish or subscribe topics across devices , that is to say, for dev1, you can only see or only allow access to WDRRDCF1T/dev1this topic and its subordinate topics, but not WDRRDCF1T/dev2its subordinate topics.

    It is not intuitive to add a rule on the platform side that does not allow access to topics across devices message, there is a potential security hole.

  2. The role of the rules engine

    Because it is not allowed to access Topic directly across devices, it is necessary to rely on the “rule engine” to manually add rules, forward the specified Topic message to another Topic, and implement communication between different devices.

The above figure introduces the main function of the rule engine “republish”, that is, republishing messages under one topic to another topic. As we can see from the figure, the rule engine WDRRDCF1TE/dev2/eventrepublishes the messages to the WDRRDCF1TE/dev1/controlnext WDRRDCF1TE/dev1/eventand republishes the messages to the WDRRDCF1TE/dev2/controlnext.

In this way, for dev1, it only needs to subscribe WDRRDCF1TE/dev1/controlto receive 25KCIUIR1G/dev2/eventmessages from it, and the same is true for dev2.

  1. Set up the rules engine

In the IoT communication interface, select “Rule Engine” – “New Rule”, and specify a rule name at will, we might as well set it to “1to2” here:

Here, we see the detailed setting information of the rule, mainly including “filter data” and “behavior action”.

The above picture is the set rule. Here, we set the filter field in the “Filter data” section to *, the filtered Topic is WDRRDCF1T/dev1/event, and the condition is set to empty, that is, the data is not filtered, all matches, and then, the operation performed is to forward the data After WDRRDCF1T/dev2/controlsetting this rule, dev2 can receive the data sent to the event by dev1 by subscribing to the control.

About the “filter data” settings:

Since we chose a custom data format when setting the data format when creating a new product, in the case of a custom data format, the current platform treats it as a binary stream, so it is impossible to filter data by matching fields.

If the data format used is json when making products, then SQL matching and filtering can be performed here according to the fields in json.

In the same way, we set a new rule “2to1” to achieve WDRRDCF1T/dev2/eventthe WDRRDCF1T/dev1/controlforwarding:

After the rule engine is set, remember to click the enable button, so that the two-way data path from dev1 to dev2 on the platform side is opened:

2.5. Cloud Logs

In the log, you can see that the log records the connection, disconnection, publishing, subscription and other behaviors of the device, and also records the operation of the rule engine, as well as some behavior logs of the CMQ queue.

2.6. Message Queue CMQ

Under the key authentication, the content of the message (payload) is encoded by base64, so the data seen on the platform side is similar to garbled code, which is actually the result of encoding. If you want to view the specific content, you can do it under Linux echo <payload> | base64 --decode.

3. Device docking test

3.1. Network access

Test whether the AT command is normal:



Set the working mode of ESP8266 as AP and STA coexist:



Set the transfer mode to normal transfer mode:



To enable multi-channel mode:



Access the network:





This information is saved to Flash and can be viewed with the following command:





3.4. Subscribing to topics



After the subscription is successful, enter the online debugging of the device in the cloud, and send the test data:
in the serial port assistant, you can see the data reported by the ESP8266 module through the URC method:

3.5. Posting a message



The returned result is:


The message reported by the device can be seen in the cloud:

4. OTA upgrade

After the module is successfully connected to the IoThub platform, perform the following operations.

4.1. Enable OTA function


The returned results are as follows:


The command is successful, and the module is already in the state of monitoring the upgrade command.

4.2. Cloud-delivered firmware

Upload the firmware to be upgraded to the [cloud platform] :
choose to release the firmware of version 0.2:
You can see the URC data reported by the module in the serial port assistant:


4.3. Read the firmware information cached by the module


The returned result is:


The firmware information obtained from the cache is as follows:

  • Firmware version: 0.2
  • Firmware size: 6892 bytes
  • Firmware MD5
  • The maximum number of bytes of the OTA firmware to be upgraded by the user, 700KB

4.4. Read the firmware data cached by the module

512 bytes per read:


When the last read, the module actually returns the read size of 236 bytes, which is less than 512 bytes, indicating the end of the read.

You may also like...

Leave a Reply

Your email address will not be published.