.
前言:
本期給大家帶來一款精緻炫酷的藍芽土壤溫溼度感測器，用於做盆栽呵護類產品.
.
1. 成品展示
淘寶上賣得比較多的主要是下面這種模組，其主要作用是測量土壤電阻(越潮溼，電阻越小;越乾燥，電阻越大)，同時賣家會提供一個adc電路，該電路有電壓比較器，可以根據可調電阻設定比較閾值，從而實現土壤溼度到達某一閾值後，直接輸出開關訊號，如果後面再接一個繼電器電路，則可以做一個簡易的自動澆花系統。
我們本次給出的也是採用相同的原理，來實現土壤溼度檢測。此外，還加了DHT11溫溼度感測器，光敏電阻。綜合實現盆栽呵護:
.
2. 原理圖解析
如下圖，整個系統有藍芽模組(既做通訊，也做MCU)，鈕釦電池電路，按鍵和指示燈電路，dht11溫溼度感測電路，基於ad取樣的土壤溼度監測電路，基於ad取樣的光敏電阻電路，以及為了實現低功耗的電源控制電路:
.
3. pcb設計
pcb設計中比較重要的部分是: 土壤溼度檢測部分。該部分需要儘可能增大與土壤的接觸面積。如下圖設計:
此外，採用鈕釦電池電路，讓整個系統輕量級; 將藍芽模組的引腳全部引出來，方便做二次開發和除錯; 按鍵用來重置裝置; 指示燈用來指示工作狀態。
.
4. 嵌入式對外提供介面
4.1 藍芽廣播
１）基本屬性：
- Advertising interval: 200 ms
- Advertising interval low-power: 1000 ms
- Advertising broadcast: always on
- Connection interval: 30 ms
2）廣播包 （Advertising Data) 分為：
- 廣播包 （Advertising Data)
- 響應包 （Scan Response）
注：主機主動掃描的情況下， 傳送掃描請求給從機， 從機返回掃描響應資料：
3）廣播包資料格式：
每個包都是 31 位元組，資料包中分為有效資料（significant）和無效資料（non-significant）兩部分。
有效資料部分 包含若干個廣播資料單元，稱為 AD Structure 。如圖所示，AD Structure 的組成是：
- 長度 Len ，表示這個 AD Structure 的長度（除去 len本身 1）
- 型別 AD Type 標記這段廣播資料代表什麼， 比如裝置名， uuid 等。
- 資料 AD data
無效資料部分 廣播包的長度必須是 31 個 byte，如果有效資料部分不到 31 自己，剩下的就用 0 補全。這部分的資料是無效的。
對於該裝置，我們約定其廣播資料格式為：
| len | kind | data | 備註 |
|---|---|---|---|
| 02 | 01 | 05 | - |
| 06 | 09 | 35:31:69:6f:74 | name:51iot |
| 10 | ff | 00:00 | 保留１ |
| 85:81:D7:9D:FF:FF | MAC 6 位元組地址，大端（順序－看著舒服的放法） | ||
| 01 | 型別－用於標誌不同的ble廣播格式 | ||
| pid (6bytes) | 產品ID，每個產品一個ID |
注：根據name過濾出屬於51iot的產品；kind=0xFF的資料放廣播響應包，其他放廣播包；
.
4.２ 藍芽服務和屬性
這裡暫時只有一個服務，服務中包含：APP->DEVICE 的具備write能力的資料下行特徵；和DEVICE->APP的具備notify能力的資料主動上報特徵．其UUID定義如下：
| 描述 | uuid | 屬性 |
|---|---|---|
| service | 000102030405060708090a0b0c0d1990 | |
| PhoneToBle | 000102030405060708090a0b0c0d1993 | write |
| BleToPhone | 000102030405060708090a0b0c0d1994 | notify |
.
4.3 資料包格式
5.4.2節主要規範了資料上行和下行的通道，本節主要規範資料應該以怎樣的格式在上述通道中傳輸．首先我們要知道藍芽上行/下行傳輸單次不能太長（專業術語叫最小傳輸單元MTU），一般２０位元組，我們這裡規定是２０位元組，多了要採用分包機制傳送．
１）最小幀長度：
MTU=20 bytes
２）格式：
| 欄位 | 意義 |
|---|---|
| 55 AA | 頭 |
| 00 | 版本 |
| cmd | 命令(1byte) |
| data_len | 資料長度(1byte) |
| data | 資料 |
| check_sum | 校驗和(除了check_sum求和對0xff取餘) |
３）dp：
我們仿照主流物聯雲平臺（塗鴉＼阿里＼小米等）對一個產品進行的數字化描述方法來對各種物聯網產品進行數字化建模．
首先所有資料被劃分為以下型別：
注：約定陣列最長不超過２５６位元組
這樣我們就能夠通過下面的方法來定義一個產品（本期的智慧盆栽系統）：
| DP ID | 功能點 | 識別符號 | 資料傳輸型別 | 功能點型別 | 功能點屬性 | 備註 | 操作 |
|---|---|---|---|---|---|---|---|
| 1 | 環境溫溼度檢測開關 | on_off_th | 可下發可上報 | 布林型 | |||
| 2 | 土壤溼度檢測開關 | on_off_soil | 可下發可上報 | 布林型 | |||
| 3 | 亮度檢測開關 | on_off_light | 可下發可上報 | 布林型 | |||
| 4 | 實時溫度 | temperature | 只上報 | 數值型 | 數值範圍：0-100, 間距：1, 倍數：0, 單位：攝氏度 | ||
| 5 | 實時溼度 | humidity | 只上報 | 數值型 | 數值範圍：0-100, 間距：1, 倍數：0, 單位：% | ||
| 6 | 實時突然溼度 | soil_humidity | 只上報 | 列舉型 | 列舉值： very_dry/dry/moist/very_moist | ||
| 7 | 實時亮度採集 | light | 只上報 | 數值型 | 數值範圍：0-100, 間距：1, 倍數：0, 單位：光強百分比% | ||
| 7 | 歷史資料上報 | history | 可下發可上報 | RAW型 | 時間戳4bytes＋１位元組的溫度＋１位元組的溼度＋１位元組的土壤溼度+1位元組的光強 |
.
4.４ 資料通訊模型
4.1～4.３對藍芽的廣播和服務對外提供的介面進行了規範和說明，此時使用常見的藍芽除錯工具（nrf connect／light blue...）都可以來驗證我們的硬體裝置是否是按照所規範的那樣：
.
看上圖第１頁面，可以看到其廣播資料和我們規定的一模一樣；看上圖第２頁面，可以看到其服務和特徵也和我們定義的一模一樣，圖３是我們向智慧盆栽裝置傳送一個dp=1，值為false的資料（表示關閉環境溫溼度採集）．因此一個APP/微信小程式開發者，可以根據4.1～4.３的規範來開發應用程式，通過廣播資訊，找到指定藍芽裝置，通過notify和write兩個通道，實現與指定藍芽裝置通訊．這裡我就不多說了，開發者可以根據該款開源硬體開放的介面，自己做各種炫酷的APP～
重要
- : 如果對該智慧盆栽開源硬體感興趣，可以微信掃碼購買樣機，自己除錯哈
- 裡面還有其它好玩有趣方案，都會以開源的PCB+標準化功能描述介面提供，開發者可以根據自己的技術棧，選擇開發不同的上位機程式，做出各種有趣的小智慧硬體～
