Disconnecting BLE after download, client side and device side

Hi,

A few questions about BLE connection and download that I couldn't find answers for in the various (very good) BLE pages - related to logic I'm implementing for switching between the device active and debug/download mode. Just want to understand the "right" way to do things:

• When using the CLI to download a program (> espruino file.js), it automatically finds/connects, but seems to stay connected after CLI has completed (on MacOS). Is there an option or preferred way to make it disconnect BLE once the application is downloaded?

• On the device, how can you see if you are currently connected? I can happily hook NRF.on('connect', ... ) and NRF.on('disconnect', ...), but want to just ask the question e.g. I might already be connected when application starts, so won't have seen any events. Was expecting Bluetooth.connected() or NRF.connected(), but they are not available. What is the preferred way to understand (in particular when the application starts running) what the BLE connection state is?

• If I do want to force a disconnect from the device side as part of my application once programming is complete (presumably using NRF.disconnect()), what is the best/preferred approach? Having disconnect as the last line in the file is probably not appropriate, as all actions of loading have probably not completed (maybe there is an onLoad() equivalent?). How do you elegantly disconnect from the device side after a programming event?

Thanks!
Simon

seems to stay connected after CLI has completed

eep. I don't have any suggestions - that's definitely not the intended behaviour! I'll take a look when I get a moment.

On the device, how can you see if you are currently connected?

It's the slight;y cryptic NRF.getSecurityStatus().connected - http://www.espruino.com/Reference#l_NRF_getSecurityStatus

You can use that on a central connection as well if you need to see if that is connected.

If I do want to force a disconnect from the device side as part of my application once programming is complete

Yes, NRF.disconnect() as the last line sounds good. In an ideal world the CLI would automatically disconnect though - I'm a bit surprised about that!

Some interesting extra findings:

Of the 3 devices I have, 1 doesn't disconnect after programming, but the other two do. Interestingly, the one that doesn't disconnect is running 2v05, and the two that do are running 2v04. Coincidence?

I don't think there is anything I have done to influence configuration/state on any of them. I have only run code from RAM. Maybe there is some bonding info or something client side where my Mac is doing something different for different devices based on history of how I have interacted with them.

Another difference occurred when I tried a Hard Reset to understand if there may be any state impacting behaviour (as described https://www.espruino.com/Pixl.js); interestingly the 2v04 devices do go through the process as described, but the 2v05 device just goes on to displaying "BOOTING" after the 10s.

Simon

1 doesn't disconnect after programming

Is it possible you're paired in Mac OS system settings? That could definitely do it.

If you were ever experimenting with Bluetooth HID that definitely does it as the OS tries to always stay connected.

2v05 device just goes on to displaying "BOOTING" after the 10s.

... but it still boots, just 1 sec after that? I modified the bootloader in 2v05 to include some of the extras from the Bangle.js one (eg reporting why there was a reboot) but the side-effect is in order to do that it adds an extra delay so you can actually see what's going on.

Generally the bootloader stays on the device and never gets updated. So far I've been sticking 2v04 on the Pixls and I had a big batch I'd made. I just stuck 2v05 on the first one I sent you, then forgot about doing it on the others :)

Is it possible you're paired in Mac OS system settings? That could definitely do it.

I had killed all pairings, so didn't think it could be that. However, I tracked down what was up:

I had a chrome window open somewhere from a few days back with the IDE loaded. It or the web BLE stack must have been hanging on to the device whenever it saw it turn up! So kill that and it is working as expected now.

On the BOOTING comment, yes, assume that is working fine, just didn't match the docs. I updated a 2v04 to 2v05 in the process to check, and all continued to work fine which helped confirm it was likely client side.

The NRF.getSecurityStatus().connected call is working fine too, and disconnect() logic is not needed now I understand the correct behaviour is it to disconnect anyway.

Thanks for your all your help!

Simon