Unable to find Bluetooth device

I am trying to connect the PuckJs to a Bluetooth device.

I have written code in JavaScript and it runs fine on the browser. I've written similar code in Python and it connects fine to the device.

However, the PuckJs just can't seem to find the device. I'm not sure why, since it's located very close to it.

The MAC address is: 4c:xx:xx:xx:xx:xx and there's also a Device Name which I can filter by using the namePrefix in JavaScript.

I've tried NRF.findDevices, NRF.setScan, the results I get are odd. There is an id field in each device, but none of them match the MAC address I want to connect to.

Anyone know what I'm missing?

The JavaScript code that works is:

  let device = await navigator.bluetooth.requestDevice({
    filters: [
      { namePrefix: 'P' }
    ],
  });
  server = await device.gatt.connect();

When migrated to use NRF, no device is found:

  NRF.requestDevice({ filters: [{ namePrefix: 'P' }], timeout: 20000 }).then(function(device) {
    console.log(device);
  });

results in no device found matching filters.

I've also tried findDevice, setScan, with a large timeout and a max of 100 devices. I do get a lot of results (expected), but not the device I want.

To confirm, I can connect to the device via Web and also Python on Raspberry Pi, just not on the PuckJs.

Thanks!

Interestingly, when I try and define a service, the PuckJS disonnects from the WebIDE and I need to power cycle the device and refresh the page to reconnect. Defining an optionalService doesn't return the device but also doesn't crash the Puck

filters: [{ services: 'c119xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' }]

Have you had success with 2.06V Puck as a BLE device like Midi or HID keyboard device? I just cant get it work with any simple provided examples.

I'm not sure what you mean? If it helps, I have around 90 bluetooth devices in my house (hue spotlights are all bluetooth enabled) and the PuckJs seems to find those with no problems. It just can't find the device it's literally cm's away from.

Could it be because I'm already connected via BLE to the Web IDE and I am trying to connect to another BLE device?

If so, how do I test connecting to a BLE device?

Not sure if this helps, but I have a pixljs that has a large lcd so I can pipe console commands there, which is what I use for exactly the issues you face (getting feedback for operations while disconnected).

You can also try using the built-in serial instead of the BLE serial so you would free up the radio.

Thanks for that, I don't see a serial port on the PuckJs?

Not sure if we're talking about the same device but http://www.espruino.com/Puck.js#serial-console

I tried to force the connection on Serial1 but now I've got an error 'Prompt not detected'

I really do wish this was simple. I was able to get this working in Python and Javascript fairly easily, something basic like finding a BLE device should be super simple :(

function onInit() {
  setTimeout(function() { Serial1.setConsole(); }, 1000);
  // ...
}

also tried

function onInit() {
  setTimeout(function() { Serial1.setConsole(true); }, 1000);
  // ...
}

You don't have to stay connected with the serial just to test that you can actually find the device. You can blink the leds for example while searching and blink differently when found.

Also, if you're moving the serial somewhere else then the webide won't show anything since you moved the console messages to the new serial.

Thanks

I'm not sure how that will help, it looks like the Puck can handle more than 1 BLE connection since it can find other BLE devices whilst connected to the WebIDE.

While it can handle more than one BLE connection, the webide can only be connected to the puck's serial. By default it's the BLE serial. If you move the Serial from BLE to the pins, then serial would be running there and webide doesn't have anything to connect to.

One other thing: are you sure the device you want to connect to is advertising? You can use nRF connect app on your phone and scan it and see if you can see it.

Another thing is that not all bluetooth is the same. Puck is a Bluetoothe Low Energy device, which is completely different from plain old bluetooth. What's the device you're trying to connect to?

Could it be because I'm already connected via BLE to the Web IDE and I am trying to connect to another BLE device?

Sorry for all the serial talk, I got confused by this. I thought you were connecting to another espruino that's also connected to another webide. The devices don't advertise (you can't connect to it) if they're already connected to a different device (which in this case is your computer).

Thanks for helping debug this issue.

I have been reverse engineering a Pure Sense fan for the past few months by inspecting packets in Wireshark on the communication between the Android App and the Fan. By this process I was able to find out the Mac address, Device Name etc.

nRF shows the device as "LE only", Advertising Type "Legacy", Complete Local Name: "Pure Sense".

"Pure Sense" is the name of the Bluetooth device list when running on Raspberry Pi (in Python) and Web Bluetooth using JavaScript.

I cannot see why the Puck would be any different.

Do you have any idea on how I can change my code to free up the serial (if that's what I need to do?) I'm not sure this is the right approach since other Bluetooth LE devices show up in the scan.

It's worth noting that the description the Puck shows for each Bluetooth device is different too, there are no friendly names shown for any devices.

No, it doesn't look like the serial issue was the problem. That was totally my misunderstanding.

Sorry I don't think I can help you with this specifically; it looks like things should be working as they should and I don't know why the fan wouldn't behave as expected.

If you're able to find it with the nRF connect app then that means it's definitely advertising (and wasn't left connected to the pi for example). Barring possible antenna orientation issues, txpower or something of the sort, I can't think of anything else that could be the issue :(

No worries, thanks for trying.

It looks like the Puck isn't working for what I wanted it to do which is connect to a BLE device and send some requests.

I'll now try and get it to connect to a Raspberry Pi via Bluetooth and see if I can get the communication to work that way, it'll just mean an even longer lag :(

You may try to enable the active flag of NRF.findDevices/setScan just in case. This does active scan i.e. requests from each device so called scan response with additional data. That could help if the name itself was not in advertisement packet but in scan response packet (possibly because advertisement packet is full of some other more important data). See more details about scan response here http://www.espruino.com/Reference#l_NRF_setScan

I don't see such flag described e.g. here https://developer.mozilla.org/en-US/docs/Web/API/Bluetooth/requestDevice so maybe doing active scan is default on other devices.

EDIT: yes looks like default is active scan in web bluetooth see https://webbluetoothcg.github.io/web-bluetooth/scanning.html#scanning

6 . Let scan be a new BluetoothLEScan instance whose fields are initialized as in the following table:
..
active true

Hi,

I'd definitely think that the Puck should be able to handle this. I see you used nRF connect - do you think you could paste up a screenshot of what you see there - specifically when you tap on 'RAW'?

As @fanoush says you might have a lot more success using an active scan, however I'm surprised you're not seeing even just the MAC address (without a name).

Otherwise I guess there's a possibility that the device is actually using some extra bluetooth features like increased advertising Payload or Bluetooth 5 stuff that may cause problems for Puck.js

You're actually based in the UK? Is the device something you'd be able to post over to me to take a look at?

Thanks for the reply Gordon.

The device is a bathroom extractor fan called Pure Sense which would be tricky to post ;-)

I did some testing over the weekend and realised I needed to disable a lot of other Bluetooth devices in order for the Puck to discover it. Once I had the ID, I was able to enable the other devices and the Puck began connecting to the fan fine.

Not sure why this was the case, but I'm super happy that it works now. Takes around 30s to connect and send data but that's not a biggie.

Thanks for helping debug it!

That's interesting - were you using an 'active' scan?

I know I've had a lot of problems with active scans in areas with a lot of bluetooth activity (even when using a PC) - the scan response never gets received.

I should add that once you've actually done a requestDevice to get a device, you can re-use that device and just call connect on it - so the second time you click the button you should be able to get things working a lot faster.

Thanks Gordon,

I'm not sure what an active scan is. I was using a slightly modified version of the script in my original question.

The button, when pressed, makes a connection to the device, reads some data and sends some data. Since I'm doing it in a promise based approach, it takes a while for the data to be read / written. It's super quick in the app (around 1s or so) but takes around 30s on the Puck. I'm using LEDs to help signify that "something is happening". Will check to ensure I'm reusing objects as much as possible, pretty sure I am though.

I'm not sure what an active scan is.

I tried to explain what it is in post #17 but no matter what exactly it is, you have used it if you added active:true to NRF. findDevices or NRF.setScan as an extra option. Default is false so you probably did not use it.

It's odd that the Puck does take so long, but it's great that it's working.

It is possible to re-use the characteristics as well - and that can provide a big speedup.

Also worth adding that if you're using findDevices rather than requestDevice, findDeviceswill wait for exactly the timeout you specified (which could be 20 sec?). requestDevice will scan for the timeout you specify as a maximum but if it finds the device earlier it'll stop