Peripheral connection not properly terminated after central enters sleep mode

[eonicum]

Environment

• Central device: MacBook with Apple Silicon
• Operating system: macOS Sequoia
• Node.js version: v20.12.2
• Library version: @stoprocent/noble v1.19.1

Use case

Implement automatic reconnection for a peripheral device after a disconnection event, such as:

1. When the central device’s Bluetooth module is disabled.
2. The central device enters sleep mode.
3. The peripheral moves out of range, or the peripheral is turned off.

Issue

The library correctly emits a stateChange event with poweredOff during sleep and poweredOn upon waking, but the following issues occur:

1. The peripheral’s state remains connected.
2. The peripheral does not trigger a disconnect event.
3. The peripheral stops receiving data or processing read/write requests.
4. If the physical peripheral device is turned off after waking, noble logs a warning: noble: unknown peripheral {connected peripheral UUID} disconnected!

Steps to reproduce

1. Connect to a peripheral (code snippet for testing).
2. Confirm the peripheral is connected.
3. Monitor the following:
   • Noble’s stateChange event
   • Peripheral’s disconnect event
   • Peripheral’s connection state
   • Ability to perform peripheral operations
4. Put the MacBook into sleep mode (e.g., close the lid for 5–7 seconds or allow it to sleep automatically).
5. Wake the MacBook.
6. Verify that stateChange events reflect poweredOff during sleep and poweredOn upon waking.
7. Observe whether:
   • The disconnect event is triggered for the peripheral
   • The peripheral’s state updates to disconnected
8. Turn off the physical peripheral device.
9. Check for any logged warnings.

Expected behavior

• When the MacBook enters sleep mode, the peripheral should trigger a disconnect event.
• The peripheral’s state should update to disconnected.
• The peripheral should be fully disconnected.
• No warning messages should be logged.

Actual behavior

• No disconnect event is triggered when the MacBook enters sleep mode.
• The peripheral’s state remains connected.
• The peripheral seems to remain connected at the OS level, but this status is not propagated to the noble library.
• Turning off the physical peripheral after waking triggers the warning: noble: unknown peripheral {connected peripheral UUID} disconnected!
• Noble correctly emits stateChange events: poweredOff during sleep and poweredOn upon waking.

Additional information

• The issue has been observed across multiple different peripheral devices.
• Testing has been conducted only on macOS due to the unavailability of other operating systems. The issue may occur on other platforms.

Investigation and potential cause

My initial assumption was that the operating system keeps devices connected, while the library marks them as disconnected. I needed to locate the code responsible for cleanup, and I found the following function

noble/lib/noble.js

Lines 90 to 100 in 3a5f04d

	Noble.prototype.onStateChange = function (state) {
	debug(`stateChange ${state}`);
	// If the state is poweredOff and the previous state was poweredOn, clean up the peripherals
	if (state === 'poweredOff' && this._state === 'poweredOn') {
	this._cleanupPeriperals();
	}
	this._state = state;
	this.emit('stateChange', state);
	};

So, I made several attempts to fix it.

Attempted fix 1

I removed the this._cleanupPeripherals() call from the onStateChange function.

Noble.prototype.onStateChange = function (state) {
  debug(`stateChange ${state}`);

  // If the state is poweredOff and the previous state was poweredOn, clean up the peripherals
  if (state === 'poweredOff' && this._state === 'poweredOn') {
    // this._cleanupPeriperals();
  }

  this._state = state;
  this.emit('stateChange', state);
};

This allowed the disconnect event to trigger and correctly updated the peripheral’s state when turning off the physical peripheral. However, if the peripheral remained powered on, its state stayed connected, but no peripheral operations (read, write, subscribe) could be performed.

I assumed that the device connection is not fully operational and requires manual closure. This assumption is supported by the following link.

Attempted fix 2

So I tried forcing disconnection when the state changes to poweredOff:

Noble.prototype.onStateChange = function (state) {
  debug(`stateChange ${state}`);

  if (state === 'poweredOff' && this._state === 'poweredOn') {
    // this._cleanupPeripherals();
    for (let peripheral of Object.values(this._peripherals)) {
      if (peripheral.state === 'connected') {
        peripheral.disconnect();
      }
    }
  }

  this._state = state;
  this.emit('stateChange', state);
};

This left the peripheral in a disconnecting state which is not ideal.

Attempted fix 3

I modified the logic to trigger disconnect after the state transitions from poweredOff to poweredOn:

Noble.prototype.onStateChange = function (state) {
  debug(`stateChange ${state}`);

  if (state === 'poweredOn' && this._state === 'poweredOff') {
    for (let peripheral of Object.values(this._peripherals)) {
      if (peripheral.state === 'connected') {
        peripheral.disconnect();
      }
    }
  }

  this._state = state;
  this.emit('stateChange', state);
};

This approach successfully triggered the disconnect event and updated the peripheral’s state.

Limitations of the fix

Third fix is good for investigation, but it is not production-ready due to the following concerns:

1. I haven’t researched how the allowDuplicates scanning parameter affects this fix, but it feels like it may cause issues.
2. Further investigation is needed to determine if this issue occurs on other platforms.
3. It may be better to address this at the native code level, such as manually triggering disconnects for each connected device when the state changes to CBManagerState.poweredOff.

   noble/lib/mac/src/ble_manager.mm

   Lines 27 to 30 in 3a5f04d

   	- (void)centralManagerDidUpdateState:(CBCentralManager *)central {
   	auto state = stateToString(central.state);
   	emit.RadioState(state);
   	}

   However, this could require JS side updates, as disconnect events might be triggered after the state change. The current implementation clears the peripherals list, which may conflict with this approach and depends on (no. 3).

Thank you! 🙏🙏🙏

I just wanted to say thank you for maintaining this repository. I really appreciate the support and improvements you make to this old library.

✨ ✨ ✨

[stoprocent]

Hey! Just a heads-up — there's a massive update in progress on this branch: https://github.com/stoprocent/noble/tree/feature/refactor-all.
I'm aiming to get everything released by Monday. It might not be fully stable yet, but I’ve refactored a lot of the old legacy code.

It’s not quite where I want it to be yet, but we’re definitely getting there.

Back to your issue — let’s revisit it after the release. I’ve made a number of changes that might directly impact your case. Thanks again for your very clear and detailed description — it’s super helpful.

[stoprocent]

Hey @eonicum, mind checking the referenced commit to see if the test covers your use case properly?

[eonicum]

Hey @stoprocent, thank you for your hard work releasing v2.0.1! The disconnect event is now emitted when the central goes to sleep. Thanks!

However, the peripheral still remains connected at the OS level, and the library logs a warning: noble: unknown peripheral {peripheral UUID} disconnected! after I turn off the peripheral device following the central's awakening.

Additionally, since the update, the data event for characteristics has stopped being emitted when a read operation is performed on a characteristic.

[stoprocent]

Gotcha, that's unexpected behavior, as the poweredOff event from macOS should terminate the connection. The solution would be to explicitly send a disconnect. Could you try adding a disconnect() call in noble.js, similar to what's shown in the screenshot?

The issue is that if the radio is genuinely off, we can't reliably depend on the disconnect() call to trigger the onDisconnect event, so the approach might feel a bit hacky. Try what I suggested earlier and let me know how it goes. In the worst case, I'll implement a macOS-specific workaround at the binding level to ensure disconnection occurs when the state changes to poweredOff. That should be straightforward to add.

[eonicum]

Unfortunately, this didn't work. The disconnect method works as expected only in the poweredOn state.

[stoprocent]

Ok i have a branch now to try to fix it. Can you try downloading this Darwin build and just replace it in node_modules/@stoprocent/noble/prebuilds in mac binary folder.
https://github.com/stoprocent/noble/actions/runs/14550247022/artifacts/2973741686

[eonicum]

Great job! It's working perfectly. 🎉🎉🎉

The only concern remaining is that the data event for characteristics is no longer emitted when a read operation is performed on a characteristic.

[stoprocent]

It has been fixed in 2.1.0 about an hour ago. Also have a look here: https://github.com/stoprocent/noble?tab=readme-ov-file#characteristic-methods
I will merge and we can close?

[stoprocent]

Wrong, I have to modify native bindings. It will be fixed in 2.1.1 in couple of minutes

[stoprocent]

Should be ready in 2.1.1. Can you re-test together with notifications/reading ? Then we close