BLE completeName #1402
Comments
Yes. As explained in multiple release notes, the Modable SDK have migrated to ESP-IDF v5. There are significant differences in many areas of the IDF, including BLE and Wi-Fi. It seems possible that this BLE behavior you observe is a result of the changes in ESP-IDF v5. We can investigate. Is there a common device (iPhone, HP printer, etc) that provides a completeName that you would recommend for reproducing this problem? |
|
the Bluetooth test is done on 7 differente devices. There are thermal printers and temperature sensors , but they aren't common devices. Just one works. So I suppose that the problem can be reproducted from a simple bluetooth device you test. |
|
The JavaScript APIs simply report the advertising packets provided by the ESP-IDF BLE stack (which uses the NimBLE API). Since I cannot see your devices, it is not possible to diagnose what is going on. I put together an extended version of the ble/scanner example The modified source code for that is below. For each device it outputs a hex dump of the advertising packet, a text dump of all the ASCII characters in the advertising packet, and the name of each field parsed out of the advertising packet. Please give that a try and post the results. Thank you. import BLEClient from "bleclient";
import GAP from "gap";
class Scanner extends BLEClient {
addresses = new Set;
onReady() {
this.startScanning({});
}
onDiscovered(device) {
const address = device.address.toString();
if (this.addresses.has(address))
return;
this.addresses.add(address);
trace(`Device: ${address} ${device.scanResponse.completeName ?? device.scanResponse.shortName ?? ""}\n`);
const data = Array.from(new Uint8Array(device.scanResponse.buffer));
trace(" ", data.map(value => value.toString(16).padStart(2, "0")).join(" "), "\n")
trace(" ", data.map(value => ((32 <= value) && (value < 127)) ? String.fromCharCode(value) : ".").join(""), "\n");
let index = 0;
while (index < data.length) {
const length = data[index++];
let type = data[index++];
for (let name in GAP.ADType) {
if (GAP.ADType[name] === type) {
type = name;
break;
}
}
trace(` type ${type}, length ${length}\n`);
index += length - 1;
}
}
}
let scanner = new Scanner; |
|
This is the report : MAC 70:B8:F6:21:DD:A2 is a Moddable Two |
|
Thanks for the trace. That all looks reasonable. The Moddable Two and temperature sensor contain the |
|
That is true, but the other devices don't contain the COMPLETE_LOCAL_NAME. The other devices are printers and sensors and by using simples App BLE scanner the complete name is showed. |
|
The JavaScript API can only provide the information that the ESP-IDF provides. The test above shows that it is doing that. There are two kinds of scans: passive and active. The advertising packets seen above are the result of a passive scan. In an active scan, the scanning device requests each device to send an additional "advertising response packet." No advertising response packets are provided by the ESP-IDF. The JavaScript BLE client requests an active scan by setting the The Moddable SDK uses the NimBLE API in the ESP-IDF. This is the recommended API for projects using only BLE (and not classic Bluetooth). Perhaps the lack of response packets is a limitation of the ESP-IDF integration of the NimBLE API. In reviewing the ESP-IDF repository and forums, it seems others have encountered this same behavior. I also ran Perhaps someone else has an idea? |
I'm running the example https://github.com/Moddable-OpenSource/moddable/blob/24e3e54fd3b66379c1f91ad92969c99f941ff4cf/examples/network/ble/scanner/main.js
on Moddable Six.
I used this example in Moddable Two with old compiler.
Now when a BLE device is discoverd, only some of them answer to device.scanResponse.completeName
To be clear I have many Bluetooth sensors and printers and only one of them work right.
In the previus version all these devices answer to device.scanResponse.completeName
No error only "undefined" like answer
Is something changed?
Regards
The text was updated successfully, but these errors were encountered: