.
前言:
本期給大家帶來一款精緻炫酷的藍牙土壤溫溼度傳感器，用於做盆栽呵護類產品.
.
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+標準化功能描述接口提供，開發者可以根據自己的技術棧，選擇開發不同的上位機程序，做出各種有趣的小智能硬件～
