有沒有對接微信小程序的例程

像是大多數(shù)的ble的app開發(fā)一樣，小程序通常也是針對特定的約定去做的，

比如firmware的開發(fā)者與小程序的開發(fā)者需要提前約定其連接時候的依據(jù):mac地址(ios可能不適用)，名稱，廣播中的uuid，以及位于廣播中自定義的數(shù)據(jù)；

????然后是一些通信時候的必要約定，service uuid，以及characteristic 的uuid；

然后是 數(shù)據(jù)收發(fā)的行為：

????主機(jī)->從機(jī)的write，wirte no respone，

????從機(jī)->主機(jī)的 notify 還是indicate方式。

對于notify/indicate 在使用前，可能需要必要的是能notify 的操作（使能cccd）

對于小程序的開發(fā)者，很明顯，網(wǎng)上有大量的實(shí)例可以參考，并且從以往的客戶對接來看，對接是基本毫無困難的(可以以CH573 evt 里面的BLE_UART 為基礎(chǔ)工程).

你好，發(fā)送接口，如果使用serviceId1 和characteristicId1 這種固定寫死為string類型的方法發(fā)送就不成功，用自動獲取的就可以，我們比對了一下實(shí)際內(nèi)容是一樣的。請幫忙看一下，謝謝！

var serviceId = this.data.write_serviceId

var characteristicId = this.data.write_characteristicId

var serviceId1 = "0000FFE0-0000-1000-8000-00805F9B34FB"

var characteristicId1 = "0000FFE1-0000-1000-8000-00805F9B34FB"

console.log(serviceId.includes('0000FFE0-0000-1000-8000-00805F9B34FB'));

console.log(serviceId == serviceId1);

console.log(typeof(serviceId));

console.log(serviceId.length);

console.log(typeof(serviceId1));

console.log(serviceId1.length);

console.log('deviceId x0x is:', deviceId);?

console.log('serviceId is:', serviceId);

console.log('serviceId is:', serviceId1);

console.log('characteristicId is:', characteristicId);

console.log('characteristicId is:', characteristicId1);?

wx.writeBLECharacteristicValue({

deviceId: deviceId,

serviceId: serviceId,

characteristicId: characteristicId,

//serviceId: '0000FFE0-0000-1000-8000-00805F9B34FB',

//characteristicId: '0000FFE1-0000-1000-8000-00805F9B34FB',

value: buffer,

wx.writeBLECharacteristicValue({

deviceId: deviceId,

serviceId: serviceId1,

characteristicId: characteristicId1,

//serviceId: '0000FFE0-0000-1000-8000-00805F9B34FB',

//characteristicId: '0000FFE1-0000-1000-8000-00805F9B34FB',

value: buffer,

您好，關(guān)于您將serviceId和characteristicId寫成固定的String類型后導(dǎo)致發(fā)送失敗的問題。我們這邊經(jīng)過驗(yàn)證后發(fā)現(xiàn)，將serviceId和characteristicId寫成固定并不是發(fā)送失敗的根本原因所在，這是我們將serviceId和characteristicId寫成固定后發(fā)送成功的案例：

導(dǎo)致您發(fā)送失敗的原因可能有一下兩點(diǎn)：

①在調(diào)用wx.writeBLECharacteristicValue()接口之前，需要先調(diào)用wx.getBLEDeviceServices()和wx.getBLEDeviceCharacterist()，獲取到serviceId和characteristicId，否則有可能導(dǎo)致發(fā)送失敗；

② 錯誤的使用了藍(lán)牙特征的 UUID，將接收的UUID錯誤的使用成了發(fā)送的UUID，如CH9143發(fā)送的serviceId為：0000FFF0和characteristicId：0000FFF2。這邊建議您在控制臺打印第一次發(fā)送的結(jié)果，確認(rèn)第一次發(fā)送結(jié)果是否真的發(fā)送成功，即errMsg: "writeBLECharacteristicValue:ok"?；蛘吒鼡Q其他UUID再試。

connect.zip

你好，我上傳了你們給的小程序參考代碼的connect.js, 我是確定在原來調(diào)用handleWrite函數(shù)里對同一個serviceID發(fā)送數(shù)據(jù)，當(dāng)數(shù)據(jù)長度為2時調(diào)用原來的ServiceId，當(dāng)長度為非2時，調(diào)用fix的string，打印出來uuid原始的和fix的內(nèi)容是一樣的。操作方式也是一樣的，請幫忙看一下具體原因，謝謝！

connect.org.zip

這是原始的connect.js。 上面圖片里已經(jīng)打印出了每次的serviceid和serviceid1等，我人眼比對了是一樣的，但是調(diào)用console.log(serviceId.includes('0000FFE0-0000-1000-8000-00805F9B34FB'));和 console.log(serviceId == serviceId1); 圖片里返回都是false，調(diào)用

console.log('serviceId is:', serviceId);

console.log('serviceId is:', serviceId1);

打印出來內(nèi)容是一樣的?？梢暂斎?個字節(jié)時走fix的string，就是發(fā)送失敗，輸入2個字節(jié)時走自動獲取的就是發(fā)送成功。

現(xiàn)在我們使用的是CH579上OTA的通道。

// OTA Profile?¨??Index?¨??

#define OTAPROFILE_CHAR? ? ? ? ? ? ? ? ?0? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

// OTA ·?????UUID?¨??

#define OTAPROFILE_SERV_UUID? ? ? ? ? ? 0xFEE0

? ??

// OTA ?¨???¨??UUID?¨??

#define OTAPROFILE_CHAR_UUID? ? ? ? ? ? 0xFEE1

發(fā)送2個字節(jié)走自動獲取的id是成功的

發(fā)送3字節(jié)走fix的string是失敗的

下圖可以看出自動獲取的和fix的內(nèi)容一樣，但是用include和==判斷返回時false。代碼里是if(len == 2)走自動獲取id，else走fix stringid，其他代碼一樣，都已經(jīng)調(diào)用過wx.getBLEDeviceServices()和wx.getBLEDeviceCharacterist()，獲取到serviceId和characteristicId，

另外補(bǔ)充說明一下，我使用的是IOS

您好，我們這邊仔細(xì)核對了一下兩種發(fā)送方式時的serviceId和characteristicId，固定時的與自動獲取的存在著差異：