1. 程式人生 > 其它 >402-STM32F103+EC200(移遠4G Cat1)基本控制篇(阿里雲物聯網平臺)-微信小程式掃碼繫結EC200並通過阿里雲物聯網平臺實現遠端通訊控制

402-STM32F103+EC200(移遠4G Cat1)基本控制篇(阿里雲物聯網平臺)-微信小程式掃碼繫結EC200並通過阿里雲物聯網平臺實現遠端通訊控制

<p><iframe name="ifd" src="https://mnifdv.cn/resource/cnblogs/ZLIOTB/EC200/aliyun.html" frameborder="0" scrolling="auto" width="100%" height="1500"></iframe></p>

 

說明

這一節實現微信小程式掃碼繫結模組並通過阿里雲物聯網平臺實現遠端通訊控制.

概要:

微信小程式和微控制器裝置分別作為裝置以動態註冊方式連線阿里雲物聯網平臺,然後通過規則引擎實現微信小程式和裝置之間通訊.

此節教程是前面所有知識點的整合,希望使用者按部就班的學習了前面的內容,然後再學習此節. 

 

微信小程式準備工作

1.在微信小程式平臺上設定域名白名單(推薦)

 

 

 

 

域名為自己裝置連線的MQTT伺服器的IP地址:

wss://{productKey} .iot-as-mqtt.{Region} .aliyuncs.com

我的productKey為: a1m7er1nJbQ

我的Region地區為: cn-shanghai

所以;  wss://a1m7er1nJbQ.iot-as-mqtt.cn-shanghai.aliyuncs.com

 

注意:設定完成以後重啟一下微信開發工具

 

 

2.如果不設定域名白名單也可以在軟體上選擇忽略校驗域名

 

測試準備

1.開啟這節的微信小程式工程和微控制器工程

提示:這節的微控制器程式就是上一節的程式,如果上一節已經下載運行了,不需要重新下載

 

2.登入自己的雲平臺

注:選擇哪個產品,裝置就會註冊到哪個產品下

 

 

3,檢視並替換自己產品的ProductSecret; ProductKey; (微控制器程式裡面和android程式裡面都需要替換)

 

 

 

 

 

 

 

4,檢視並替換自己instanceId

提示:在2021年7月30日之前購買的例項是沒有 instanceId 的, 程式裡面可保持空

 

提示:有 instanceId 的, 填寫上例項的 instanceId

 

 

 

 

 

配置規則引擎

1.規則引擎 ,雲產品流轉,建立規則

 

 

 

 

 

2.選擇編寫 SQL

 

 

 

 

3.新增操作

 

 

 

4.注意①自己填寫   ${TargetDevice}

 

 

 

5.啟動規則

 

 

 

 

 

 

 

 

測試

1.修改完成以後編譯下載微控制器程式

微控制器日誌列印訂閱主題成功說明微控制器程式正常執行

 

 

 

2.在平臺上可以看到在相應的產品下面註冊了裝置

注:裝置名字使用的是模組的IMEI號

 

 

 

4.點選編譯預覽,微信掃碼安裝到手機

 

5.執行APP會彈出註冊頁面.

注:這個步驟是讓微信小程式在物聯網平臺上註冊個裝置,讓微信小程式接入雲平臺.

裝置的名字做成了需要使用者去填寫,使用者如果做產品的話可以用使用者的手機號替代.

 

6.填寫 222222(隨意哈) 後點擊 註冊裝置

 

 

 

7.註冊成功將會跳轉到主頁

 

 

 

8.在平臺上可以看到在相應的產品下面註冊了裝置

 

 

9.新增裝置

 

10.掃碼新增

 

 

11.掃描裝置的二維碼

 

 

12.掃描成功以後,自動跳轉到主頁面,並添加了一個裝置

顯示的為裝置的IMEI號

 

 

13.點選裝置進入裝置控制頁面

 

 

 

整體通訊流程說明

1.通訊流程詳細說明

微信小程式和微控制器各自作為阿里雲的裝置接入阿里雲伺服器.

微信小程式接入的名字為使用者註冊時填寫的名字;

微控制器接入的名字為模組的IMEI號;

微信小程式新增裝置的時候新增的模組的IMEI號.

 

假設微信小程式註冊的裝置的名字為: 111111

假設模組的IMEI為: 868591050594364

 

APP釋出的主題: /a1m7er1nJbQ/111111/user/update

APP釋出的訊息為: {"TargetDevice":"868591050594364","DeviceName":"111111","data":"switch","status":"1"}    (以控制繼電器吸合的資料為例子)

注:

TargetDevice 欄位的值是微信小程式掃碼新增的裝置的名字

DeviceName 欄位的值是微信小程式本身裝置的名字.

 

這個主題發給雲平臺以後,經過了轉發規則裡面的SQL語句

 

 

 

 

注: /a1m7er1nJbQ/+/user/update  (裡面的 + 代表任意)

微信小程式釋出的主題為 /a1m7er1nJbQ/111111/user/update  符合咱設定的規則.規則便會提取這個主題裡面的訊息.

 

 然後下面的配置是對提取的訊息進行操作

 

 

 

 

 

釋出到另一個 Topic    /a1kalhdMH2Z/${TargetDevice}/user/get 

${TargetDevice}意思是提取訊息裡面欄位為 TargetDevice 的欄位值,然後替換上面的  ${TargetDevice}

咱的訊息是 {"TargetDevice":"868591050594364","DeviceName":"111111","data":"switch","status":"1"}

所以最終訊息轉發給下面的主題(也就是微控制器訂閱的主題)

/a1m7er1nJbQ/868591050594364/user/get 

然後微控制器就收到了訊息 {"TargetDevice":"868591050594364","DeviceName":"111111","data":"switch","status":"1"}

 

微控制器接收到訊息以後,提取 "DeviceName":"111111"

然後用自己的釋出主題釋出訊息  

釋出的主題: /a1m7er1nJbQ/868591050594364/user/update

釋出的訊息: {"TargetDevice":"111111","DeviceName":"868591050594364","data":"switch","status":"1"}

 

TargetDevice 欄位的值改為了 111111

DeviceName 欄位的值為微控制器裝置的名字  868591050594364

 

訊息發給了伺服器,然後經過轉發規則,同理 ,訊息便會轉發給了微信小程式

 

 

微控制器程式說明

微控制器程式就是前面的動態註冊, 規則引擎 的結合

APP和裝置通訊使用的是自定義主題.

裡面的大部分都是前面的程式, 只是增加了訂閱自定義的主題

還有就是在接收回調函式裡面接收並處理資料.

 

1,連線伺服器, 註冊裝置, 裝置連線MQTT伺服器

 

 

 

 

 

 

 

 

 

 

 

 

 

2.連線成功之後訂閱主題

 

 

 

 

3.在MQTT回撥函式裡面接收處理和返回訊息

 

 

 

 

微信小程式程式說明

1.如果微信小程式沒有註冊,跳轉到註冊裝置頁面

 

 

 

2.點選按鈕註冊裝置,並把註冊資訊儲存以後跳轉到主頁面

 

 

 

3.註冊以後,內部的MQTT會自動連線

 

 

 

 

4.點選新增裝置,進入新增裝置頁面

 

 

5.點選掃碼新增, 掃碼成功, 攜帶著資料跳轉到主頁

 

 

 

 

6.在index把接收的資料儲存起來

 

 

 

7.在onShow顯示資料

 

 

8.點選裝置,攜帶著提取點選的裝置名字跳轉到控制頁面

 

 

9.使用productKey和deviceName,並拼接其自定義的主題;  使用傳遞過來的裝置名稱來拼接各種資料指令

 

 

 

11.微信小程式訂閱自身的自定義主題

 

 

 

 

 

12.定時請求裝置資料

 

 

13.點選按鈕傳送控制繼電器指令

 

 

14.接收資料

 

 

 

 

 

細節說明

1.微信小程式每隔一段時間傳送查詢繼電器狀態和查詢溫溼度資料

如果傳送完查詢命令之後裝置返回了資料,則裝置線上

如果在下次查詢時,裝置上次沒有返回資料,則認為裝置離線

 

 

 

 

2.建議使用者優化的問題

現在是每隔一段時間查詢繼電器狀態會出現一個問題: (假設是控制繼電器吸合)

如果剛剛傳送了查詢繼電器狀態,然後使用者突然點選了控制繼電器的按鍵,

這樣子的話會發送了一個查詢和一個控制指令給裝置, 裝置會先返回繼電器狀態(繼電器是斷開狀態)

裝置呢再返回控制狀態(繼電器吸合狀態)

所以就會發現APP那個按鍵先變為吸合狀態,然後又變為斷開狀態, 然後又變為吸合狀態.

建議使用者查詢繼電器狀態的時候呢,只要查詢上了繼電器狀態就不要去查詢了.

 

但是呢又來個問題, 如果是多個人使用APP控制裝置繼電器呢? 

我這邊不去查詢的話,又不能知道裝置的真實狀態了, 咱需要讓裝置主動上報才可以.

那麼就需要微控制器去記錄所有的APP裝置名稱, 傳送資料的時候呢,

輪訓把訊息傳送給每個控制過自己的APP.

但是呢,微控制器不能無限的去記錄各個APP的名稱, 咱希望的是有限的記錄, 並且可以對這些APP進行等級排序

經常控制裝置的APP呢就把它記錄到前面, 不經常甚至是太久遠的呢可以自動去丟棄掉.

為此我設計了一套快取

https://www.cnblogs.com/yangfengwu/p/14164215.html

 

實現的話大傢伙去實現吧, 現在程式裡面之所以沒加上是為了便於大家入門