一、什么是ESP01-S

如圖，不多解釋了。
參數(shù)：

這里注意的是，頻譜范圍是2.4GHZ，所以連接WIFI時只支持2.4HGZ的頻段，不支持5Ghz頻段。另外，供電是3.3V，這里讓單片機給其供電即可。
電路圖：

二、使用AT指令進行測試

拿到手的ESP01S，首先要驗證其功能是否正常，這里我用ESP01S連接USB轉串口模塊，并與電腦上的串口調試助手進行通信。

1.AT指令

AT命令組成和通訊過程
AT命令由三個部分組成，分別是前綴、主體和結束符。其中前綴由字符 AT 構成；主體由命令、參數(shù)和可能用到的數(shù)據(jù)組成；結束符一般為 (“\r\n”)。

比如 AT+CWMODE=3\r\n 這條命令，AT就是前綴，中間就是主體部分，\r\n 就是結束符。

AT命令通訊過程的實現(xiàn)，需要AT Client 和 AT Server 兩部分共同完成。

AT客戶端和AT服務器之間硬件通訊接口，一般最常用的是串口，也有SPI接口等。

AT Client主要作用是主動發(fā)送AT命令，然后等待AT Server的響應數(shù)據(jù)，并對響應數(shù)據(jù)或者AT Server主動發(fā)送的數(shù)據(jù)（即URC數(shù)據(jù)）進行解析。

AT Server 返回給 AT Client 的數(shù)據(jù)有兩種。命令響應數(shù)據(jù)和 URC 數(shù)據(jù)（unsolicited result code）。

命令響應數(shù)據(jù)：AT Client 發(fā)送命令后 AT Server 回應的響應狀態(tài)和信息。

URC數(shù)據(jù)：AT Server 主動發(fā)送給 AT Client 的數(shù)據(jù)。比如 AT Server接收到網(wǎng)絡的數(shù)據(jù)后，會主動把這些數(shù)據(jù)發(fā)送給 AT Client ，又或者 WIFI 斷開連接等，也會主動發(fā)數(shù)據(jù)告知 AT Client。

2.基于ESP01的AT指令

3.測試

打開串口調試助手，

AT+GMR指令用于獲取ESP8266模塊的固件版本號和SDK版本號。根據(jù)返回信息，可以得到以下信息：

AT version：模塊使用的AT指令版本號，這里是2.3.0.0-dev。
SDK version：模塊使用的SDK版本號，這里是v3.4-22-g967752e2。
compile time：固件編譯日期和時間，這里是Jun 30 2021 11:28:20。
Bin version：ESP8266模塊的固件版本號，這里是2.2.0(ESP8266_1MB)。
通過這些信息，可以了解ESP8266模塊的軟件版本和開發(fā)時間等信息。

AT+CIFSR指令用于獲取ESP8266模塊的IP地址。根據(jù)返回信息，可以得到以下信息：
busy p…：這個表示模塊正在忙碌中，可能是在連接WiFi網(wǎng)絡或者建立TCP連接等操作。
+CIFSR:APIP,“192.168.4.1”：這個表示模塊當前的IP地址是192.168.4.1，這是一個局域網(wǎng)IP地址，通常用于ESP8266模塊作為WiFi熱點時的地址。
+CIFSR:APMAC,“ae:0b:fb:f6:98:22”：這個表示模塊當前的MAC地址是ae:0b:fb:f6:98:22，MAC地址是網(wǎng)絡通信中用于識別設備的唯一標識符。
根據(jù)返回信息，可以看出ESP8266模塊當前作為WiFi熱點工作，并且其IP地址是192.168.4.1。

三、MQTT協(xié)議

1.MQTT協(xié)議是什么？

MQTT（Message Queue Telemetry Transport）是一種輕量級的、基于發(fā)布/訂閱模式的消息傳輸協(xié)議，主要用于物聯(lián)網(wǎng)設備與服務器之間的通信。MQTT協(xié)議最初由IBM公司開發(fā)，目前已經(jīng)成為一種開放的、國際標準的協(xié)議。

MQTT協(xié)議的特點如下：
輕量級：MQTT協(xié)議設計非常簡潔，傳輸?shù)南㈩^部非常小，可以在網(wǎng)絡帶寬較小的情況下快速傳輸數(shù)據(jù)。
發(fā)布/訂閱模式：MQTT協(xié)議采用發(fā)布/訂閱模式，可以將各種設備、傳感器、應用程序等連接在一起，形成一個可擴展的網(wǎng)絡。
QoS級別：MQTT協(xié)議支持三種QoS級別，可以確保消息的可靠傳輸。QoS 0表示最多一次傳輸，QoS 1表示至少一次傳輸，QoS 2表示恰好一次傳輸。
保留消息：MQTT協(xié)議支持保留消息，可以將最新的消息保留在服務器上，以供新的訂閱者使用。
遺囑消息：MQTT協(xié)議支持遺囑消息，可以在客戶端異常斷開時，向服務器發(fā)送一條遺囑消息，以通知其他客戶端。
安全性：MQTT協(xié)議支持TLS/SSL加密傳輸，可以確保消息的安全性。

2.topic和payload

MQTT協(xié)議中的消息由兩個部分組成：topic和payload。其中，topic表示消息的主題，payload表示消息的內(nèi)容。

Topic是一個字符串，用于標識消息的主題。在MQTT中，topic采用樹形結構組織，以“/”分隔不同的層級。例如，一個topic可以是“/sensors/temperature”，表示溫度傳感器的數(shù)據(jù)。在訂閱和發(fā)布消息時，需要指定相應的topic。

Payload是消息的內(nèi)容，可以是任意格式的數(shù)據(jù)。在MQTT中，payload可以是二進制數(shù)據(jù)、JSON數(shù)據(jù)、XML數(shù)據(jù)等，具體格式由應用程序自行定義。Payload的大小可以根據(jù)實際情況進行調整，通常建議不要超過最大的消息限制。

在MQTT中，訂閱者可以訂閱多個不同的topic，以接收不同的消息。當一個消息被發(fā)布時，MQTT服務器會將該消息轉發(fā)給所有訂閱了相應topic的客戶端。這種發(fā)布/訂閱的模式可以實現(xiàn)一對多的消息傳輸，使得MQTT協(xié)議具有很強的擴展性和靈活性。

3.MCU如何利用MQTT協(xié)議？

首先，傳感器要采集數(shù)據(jù)，可以用各種模塊采集比如溫濕度、光照強度、距離等等數(shù)據(jù)。

然后，將數(shù)據(jù)與主題等信息按照特定的格式打包成MQTT協(xié)議包。

接著，通過TCP傳輸?shù)組QTT服務器上。

下一步，MQTT服務器根據(jù)主題和信息向訂閱了此主題的設備發(fā)送MQTT協(xié)議包。

最后，接收端按照規(guī)則解析協(xié)議包，并提取數(shù)據(jù)。

4.MQTT的服務器、客戶端

在MQTT協(xié)議通訊中，有兩個最為重要的角色。它們分別是服務端和客戶端。首先我們來初步了解一下它們。

MQTT服務端
MQTT服務端通常是一臺服務器。它是MQTT信息傳輸?shù)臉屑~，負責將MQTT客戶端發(fā)送來的信息傳遞給MQTT客戶端。MQTT服務端還負責管理MQTT客戶端。確?？蛻舳酥g的通訊順暢，保證MQTT消息得以正確接收和準確投遞。

MQTT客戶端
MQTT客戶端可以向服務端發(fā)布信息，也可以從服務端收取信息。我們把客戶端發(fā)送信息的行為成為“發(fā)布”信息。而客戶端要想從服務端收取信息，則首先要向服務端“訂閱”信息?！坝嗛啞毙畔⑦@一操作很像我們在視頻網(wǎng)站訂閱某一部電視劇。當這部電視劇上新后，視頻網(wǎng)站會向訂閱了該劇的用戶發(fā)送信息，告訴他們有新劇上線了。

MQTT主題
剛剛我們在講解MQTT客戶端訂閱信息時，使用了用戶在視頻網(wǎng)站訂閱電視劇這個例子。在MQTT通訊中，客戶端所訂閱的肯定不是一部部電視劇，而是一個個“主題”。MQTT服務端在管理MQTT信息通訊時，就是使用“主題”來控制的。

1.如何讓客戶端連接到服務器端？

首先MQTT客戶端將會向服務端發(fā)送連接請求。該請求實際上是一個包含有連接請求信息的數(shù)據(jù)包。這個數(shù)據(jù)包的官方名稱為CONNECT。

MQTT服務端收到客戶端連接請求后，會向客戶端發(fā)送連接確認。同樣的，該確認也是一個數(shù)據(jù)包。這個數(shù)據(jù)包官方名稱為CONNACK。

以上就是MQTT客戶端在連接服務端的兩步操作。接下來，我們一起來了解一下客戶端在連接服務端時所發(fā)送的CONNECT報文內(nèi)容。

CONNECT – 連接服務端
在上面的描述中我們看到。MQTT客戶端要想連接服務端，首先要向服務端發(fā)送CONNECT報文。如果此CONNECT報文的格式或內(nèi)容不符合MQTT規(guī)范，則服務器會拒絕客戶端的連接請求。

下圖是CONNECT報文所包含的信息內(nèi)容。

所謂報文就是一個MQTT數(shù)據(jù)包。這個數(shù)據(jù)包中可能包含有多個信息。比如以上圖片就是描繪了一個CONNECT報文（數(shù)據(jù)包）的詳細內(nèi)容。

在這個CONNECT報文（數(shù)據(jù)包）中包含有多個信息。上圖左側欄中的內(nèi)容是CONNECT報文所包含的信息名稱。右側是信息的具體內(nèi)容。如上圖示例中，此CONNECT報文包含有名稱為clientId的信息，該信息的內(nèi)容是”client-1″。當然，上圖只是一個示例，不是所有的CONNECT報文中的clientId信息內(nèi)容都是”client-1″。

另外也請注意，上圖中有些信息名稱旁邊標注了“可選”字樣，而有些則沒有。那些沒有標注“可選”字樣的信息是必須包含在CONNECT報文中的。而對于標注了“可選”字樣的信息，CONNECT報文既可以包含它們也可以沒有它們。

（1）CONNECT報文具體內(nèi)容

clientId – 客戶端ID
ClientId是MQTT客戶端的標識。MQTT服務端用該標識來識別客戶端。因此ClientId必須是獨立的。如果兩個MQTT客戶端使用相同ClientId標識，服務端會把它們當成同一個客戶端來處理。通常ClientId是由一串字符所構成的，如上圖所示，此示例中的clientID是“client-1”。

cleanSession – 清除會話
所謂“清除會話”這一翻譯源自MQTT官方文檔中文版。要說明cleanSession的具體含義，首先要從MQTT網(wǎng)絡環(huán)境講起。MQTT客戶端與服務端的連接可能不是非常穩(wěn)定，在不穩(wěn)定的網(wǎng)絡環(huán)境下，要想保證所有信息傳輸都能夠做到準確無誤，這是非常困難的。因此，我們就要根據(jù)客戶端對系統(tǒng)運行的重要性來區(qū)別對待。有些MQTT客戶端對整個系統(tǒng)運行起著關鍵作用，這些客戶端一定要準確無誤的收到服務端發(fā)來的報文。比如一輛自動駕駛汽車的導航系統(tǒng)。假如這個導航系統(tǒng)錯過了服務端發(fā)來的報文，可能會導致交通事故甚至人員傷亡。因此，即使網(wǎng)絡不是非常穩(wěn)定，我們?nèi)匀灰笃噷Ш较到y(tǒng)一定要準確無誤的收到服務端所發(fā)來的報文。
但是有些MQTT客戶端對整個系統(tǒng)運行并不是很重要。比如同樣是這輛自動駕駛汽車。它的音樂播放系統(tǒng)如果沒有及時收到服務端發(fā)來的音樂播放報文，這對駕駛系統(tǒng)來說影響不大。

以上所舉的兩個例子說明，MQTT通訊中有些客戶端必須準確無誤的收到報文，有些則不需要。
為了保證重要的MQTT報文可以被客戶端準確無誤的收到。在服務端向客戶端發(fā)送報文后，客戶端會向服務端返回一個確認報文。如果服務端沒有收到客戶端返回的確認報文，那么服務端就會認為剛剛發(fā)送給客戶端的報文沒有被準確無誤的送達。在這種情況下，服務端將會執(zhí)行以下兩個操作：
操作1：將尚未被客戶端確認的報文保存起來
操作2：再次嘗試向客戶端發(fā)送報文，并且再次等待客戶端發(fā)來確認信息。
講到這里就要看看cleanSession的作用了。
如果cleanSession 被設置為“true”。那么服務端不需要客戶端確認收到報文，也不會保存任何報文。在這種情況下，即使客戶端錯過了服務端發(fā)來的報文，也沒辦法讓服務端再次發(fā)送報文。其實我們從字面上也很容易理解。cleanSession 的第一個詞是clean。這個詞的意思是clean（干凈）的。服務端一旦發(fā)送完報文，就會把報文忘得“干干凈凈”了。
反過來，如果我們將cleanSession 設置為”false”。那么服務端就知道，后續(xù)通訊中，客戶端可能會要求我保存沒有收到的報文。
從以上的描述不難看出，如果某個客戶端用于收發(fā)非常重要的信息（比如前文示例中汽車自動駕駛系統(tǒng)），那么該客戶端在連接服務端時，應該將cleanSession設置為”false”*。這樣才能讓服務端保存那些沒有得到客戶端接收確認的信息。以便服務端再次嘗試將這些重要信息再次發(fā)送給客戶端。
相反的，如果某個客戶端用于收發(fā)不重要的信息（比如前文示例中車載音樂系統(tǒng)）那么該客戶端在連接服務端時，應該將cleanSession設置為”true”。
請注意，如果需要服務端保存重要報文，光設置cleanSession 為false是不夠的，還需要傳遞的MQTT信息QoS級別大于0。
如果想讓服務器記住重要報文，那么客戶端在連接服務端時，需要把cleanSession中設置為false。這一點非常關鍵，請務必牢記。

keepAlive – 心跳時間間隔

MQTT服務端運行過程中，當有客戶端因為某種原因斷開了與服務端的連接，服務端需要實時了解這一情況。KeepAlive （心跳時間間隔）正是用于服務端了解客戶端連接情況的。不過關于KeepAlive （心跳時間間隔）目前講解還為時過早，我們會在后續(xù)的課程中給您做詳細介紹。目前您只需要記住，KeepAlive用于服務端實時了解客戶端是否與其保持連接的情況。

（2）CONNACK報文詳細內(nèi)容。

CONNACK – 確認連接請求
下圖是CONNACK報文所包含的信息內(nèi)容。

returnCode – 連接返回碼

當服務端收到了客戶端的連接請求后，會向客戶端發(fā)送returnCode(連接返回碼)，用以說明連接情況。如果客戶端與服務端成功連接，則返回數(shù)字“0”。如果未能成功連接，連接返回碼將會是一個非零的數(shù)值，具體這個數(shù)值的含義，請見下表：

sessionPresent – 當前會話

要說明sessionPresent，首先我們要回顧一下CONNECT報文中的cleanSession – 清除會話。

我們還用自動駕駛汽車為例。對于自動駕駛汽車來說，自動導航系統(tǒng)屬于非常重要的MQTT客戶端。服務端發(fā)送給導航系統(tǒng)的報文必須要準確無誤的送達。相反，音樂播放系統(tǒng)就不那么重要了。即使音樂播放系統(tǒng)錯過服務端發(fā)送的報文也沒有關系。

對于不重要的MQTT客戶端，它們在向服務器發(fā)送連接請求時，CONNECT報文中的cleanSession通常設置為true。原因是這類不重要的MQTT客戶端即使丟失信息也不會影響整體系統(tǒng)運行。因此服務端在看到客戶端的cleanSession為true時，就不會保存發(fā)送給它們的信息。

然而對于汽車導航系統(tǒng)這類重要的MQTT客戶端來說。當它在連接服務端時，cleanSession肯定時設置為false。原因是重要客戶端需要服務端確保信息發(fā)送準確無誤。如果服務端發(fā)現(xiàn)發(fā)送給重要客戶端的信息沒有得到確認，會將報文進行保存。

當重要客戶端連接服務端時，服務端可能保存著沒有得到確認的報文。如果是這樣的話，那么客戶端在連接服務端時，就會通過sessionPresent來了解服務端是否有之前未能確認的信息。

下面我們分幾種情況來講述sessionPresent的作用。

首先，當客戶端發(fā)送的CONNECT報文中的cleanSession設置為true。在這種情況下，客戶端是不需要服務端保存任何報文的。那么服務端發(fā)送的確認連接CONNACK報文中，sessionPresent肯定是false，也就是說，服務端沒有保存任何報文。

當客戶端發(fā)送的CONNECT報文中的cleanSession設置為false時，客戶端是要求服務端保存報文的。在這種情況下，如果服務端的確保存了沒有收到客戶端接收確認的報文信息，那么cleanSession為true，否則為false。

簡言之，CONNACK報文的sessionPresent與CONNECT報文的cleanSession相互配合。其作用是客戶端發(fā)送連接請求時，服務端告知客戶端有沒有保存報文信息。這個被服務端保存的報文信息是來自于上一次客戶端連接時，服務端曾經(jīng)發(fā)送此報文給客戶端，但是發(fā)送后沒有收到客戶端接收確認。

2.QOS等級

MQTT協(xié)議中定義了三個服務質量等級（QoS，Quality of Service），分別是QoS0、QoS1和QoS2。

QoS0：最多一次（At most once），消息發(fā)布者只發(fā)送一次消息，不保證消息能夠被接收端接收到；
QoS1：最少一次（At least once），消息發(fā)布者保證消息至少被接收端接收一次，但可能會重復發(fā)送；
QoS2：恰好一次（Exactly once），消息發(fā)布者保證消息恰好被接收端接收一次，確保消息不會重復發(fā)送。
QoS等級越高，消息傳輸?shù)目煽啃栽礁?，但同時也會增加網(wǎng)絡通信的負擔和延遲。在選擇QoS等級時需要根據(jù)實際場景和需求進行選擇。

5.用esp8266連接云平臺，并上傳溫濕度數(shù)據(jù)，這到底屬于發(fā)布主題還是訂閱主題呢？

這屬于發(fā)布主題。因為設備（esp8266）將溫濕度數(shù)據(jù)發(fā)布到云平臺，相當于發(fā)布了一個主題（topic），而在MQTT協(xié)議中，發(fā)布主題是由設備發(fā)起的。訂閱主題則是由應用程序或服務發(fā)起的。

另外，esp8266訂閱主題的場景，一般是在需要接收云平臺或其他設備發(fā)送的指令或控制信號時使用。例如，一個智能家居系統(tǒng)中，esp8266作為控制設備，可以訂閱云平臺或其他設備發(fā)布的控制主題，接收控制指令并執(zhí)行相應的操作，如打開燈、調節(jié)溫度等。另外一個常見的場景是MQTT消息隊列中間件的測試，esp8266可以訂閱測試主題，接收和驗證MQTT消息隊列的功能是否正常。

總的來說，esp8266上傳溫濕度數(shù)據(jù)屬于發(fā)布主題，接收云平臺的控制指令屬于訂閱主題。

6.主題TOPIC和消息PAYLOAD

MQTT協(xié)議中，主題（Topic）是一個層級結構的字符串，用于標識消息的類型、內(nèi)容或者目標。而消息（Message）則是實際傳輸?shù)臄?shù)據(jù)，包含了主題和負載（Payload），負載是消息的實際內(nèi)容，可以是任何二進制數(shù)據(jù)。

簡單來說，主題是消息的標識符，用于將相同類型或目標的消息歸為一類，而消息則是具體傳輸?shù)膬?nèi)容。可以把主題看作是消息的分類，而消息則是具體的數(shù)據(jù)。在MQTT中，發(fā)布者通過指定主題來發(fā)布消息，訂閱者通過訂閱主題來接收相應的消息。

7.用esp8266向云平臺上傳溫濕度數(shù)據(jù)，怎么利用主題和消息呢？

在使用MQTT協(xié)議上傳溫濕度數(shù)據(jù)到云平臺時，需要定義一個特定的主題（Topic），用于標識上傳的數(shù)據(jù)類型。例如，您可以定義一個名為“temperature/humidity”的主題，用于上傳溫濕度數(shù)據(jù)。當esp8266上傳溫濕度數(shù)據(jù)時，需要將數(shù)據(jù)打包成一個消息（Message），并指定主題為“temperature/humidity”。

具體步驟如下：

①連接MQTT服務器：使用esp8266連接到MQTT服務器，建立連接。

②訂閱主題：在連接成功后，esp8266可以訂閱“temperature/humidity”主題，以便接收云平臺的控制指令。

③上傳數(shù)據(jù)：將溫濕度數(shù)據(jù)打包成一個消息，并指定主題為“temperature/humidity”，通過MQTT協(xié)議上傳到云平臺。

④接收控制指令：如果云平臺需要控制esp8266，可以通過MQTT協(xié)議發(fā)布一個控制指令，主題為“temperature/humidity”，esp8266會接收到這個消息并執(zhí)行相應的操作。

總之，利用MQTT協(xié)議上傳溫濕度數(shù)據(jù)到云平臺，需要定義一個特定的主題，并將上傳的數(shù)據(jù)打包成一個消息，通過MQTT協(xié)議上傳到云平臺。同時，還需要訂閱云平臺發(fā)布的控制主題，以便接收控制指令。文章來源地址http://www.zghlxwxcb.cn/news/detail-704449.html

到了這里，關于STM32進階學習（1）-ESP01-S的AT指令測試、MQTT原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！