'stateChange' is not reliably triggered on Raspberry Pi 4

[fquirin]

Hi,

I've been trying to fix a number of issues that occur every time I'm trying to use noble on my Raspberry Pi 4, OS 13 (Trixie) and toggle my Bluetooth adapter.

The 1st one was discussed in issue #61 and was fixed in v2.3.13.

The 2nd one was that the stop function doesn't work on the RPi, because the PollSocket thread gets stuck in the loop waiting endlessly for a signal. This is apparently an issue specific to Linux and RPi and can be solved by the pull request of @wwaaijer discussed in issue #30 .

Now I'm stuck at a problem where the 'stateChange' event for 'poweredOn' doesn't trigger when the Bluetooth adapter starts in state 'power off'.

Here is the code to reproduce the error:

import noble from '@stoprocent/noble';

try {
  noble.on('stateChange', function (state) {
    console.log("Node.js - state change:", state);
  });

  // Wait for Adapter poweredOn state
  console.log("Node.js - wait for power on");
  await noble.waitForPoweredOnAsync(30000);

  // Start scanning first
  console.log("Node.js - start scan");
  await noble.startScanningAsync();
  console.log("Node.js - scan started");

  // Use the async generator with proper boundaries
  for await (const peripheral of noble.discoverAsync()) {
    console.log(`Node.js - Found device: ${peripheral.advertisement.localName || 'Unknown'}`);
  }

  // Clean up after discovery
  console.log("Node.js - stop scan");
  await noble.stopScanningAsync();
  console.log("Node.js - stopped scan");

} catch (error) {
  console.error('Node.js - Discovery error:', error);
  console.log("Node.js - stop scan");
  await noble.stopScanningAsync();
  console.log("Node.js - stopped scan");

  console.log("Node.js - reset noble");
  noble.reset();
  console.log("Node.js - stop noble");
  noble.stop();
  console.log("END");
}

And here are the steps:

• Open bluetoothctl and start with power off
• Run the test script with node test.js
• Switch on the adapter with power on (in the bluetoothctl terminal)
• Observe the log

I've added some DEBUG logs to BluetoothHciSocket.cpp, to better understand what's going on:

...
Node.js - wait for power on
C++ DEBUG: Called 'Start'
C++ DEBUG: PollSocket thread started
Node.js - state change: poweredOff
C++ DEBUG: Called 'Start'
C++ DEBUG: waiting for old thread to stop ...
C++ DEBUG: PollSocket thread left loop. Closing ...
C++ DEBUG: PollSocket thread started
Node.js - Discovery error: Error: Timeout waiting for Noble to be powered on
    at Timeout._onTimeout (/home/pi/node-beacon-scanner/node_modules/@stoprocent/noble/lib/noble.js:171:16)
    at listOnTimeout (node:internal/timers:581:17)
    at process.processTimers (node:internal/timers:519:7)
Node.js - stop scan
Node.js - stopped scan
Node.js - reset noble
Node.js - stop noble
C++ DEBUG: Called 'Stop'
C++ DEBUG: PollSocket thread left loop. Closing ...
END

It seems the 'poweredOn' event is never recognized, there are no Bluetooth events registered and after 30s the whole script times out. Notably the initial state of 'power off' is recognized as the first 'state change: poweredOff' event.
If I start the other way round with 'power on' I can detect events and I can shut down the script once with 'power off', but after that I'm stuck.

Any ideas what might be going on here?

Ty,
Florian

[fquirin]

[EDIT] The workaround below does not work entirely. See this comment plz.

I found a rather drastic workaround by simply creating a new instance of noble on every poweredOn/Off event.
Not sure how healthy this is though. The first switch from 'poweredOff' to 'poweredOn' will obviously still fail and trigger the timeout, but the new instance seems to work fine (until the next change event):

import { withBindings } from '@stoprocent/noble';

var restartOnPoweredOff = true;
var maxRetry = 5;
var triedN = 0;

while (restartOnPoweredOff) {
  try {
    //get a fresh instance
    var noble = withBindings('default');

    noble.on('stateChange', function (state) {
      console.log("Node.js - state change:", state);
    });

    // Wait for Adapter poweredOn state
    console.log("Node.js - wait for power on");
    await noble.waitForPoweredOnAsync(15000);

    // Start scanning first
    console.log("Node.js - start scan");
    await noble.startScanningAsync();
    console.log("Node.js - scan started");

    // Use the async generator with proper boundaries
    for await (const peripheral of noble.discoverAsync()) {
      console.log(`Node.js - Found device: ${peripheral.advertisement.localName || 'Unknown'}`);
    }

    // Clean up after discovery
    console.log("Node.js - stop scan");
    await noble.stopScanningAsync();
    console.log("Node.js - stopped scan");
    console.log("Node.js - reset noble");
    noble.reset();
    console.log("Node.js - stop noble");
    noble.stop();

  } catch (error) {
    console.error('Node.js - Discovery error:', error);
    console.log("Node.js - stop scan");
    await noble.stopScanningAsync();
    console.log("Node.js - stopped scan");

    console.log("Node.js - reset noble");
    noble.reset();
    console.log("Node.js - stop noble");
    noble.stop();
  }
  if (restartOnPoweredOff && triedN < maxRetry){
    console.log("TRY AGAIN");
    triedN++;
  } else {
    restartOnPoweredOff = false;
    console.log("END");
  }
}

[stoprocent]

I will start complete rewrite of noble soon. All typescript. Im working on plan and architecture that I can control and then I will let @claude do the implementation.

[fquirin]

I will start complete rewrite of noble soon. All typescript. Im working on plan and architecture that I can control and then I will let @claude do the implementation.

Sounds like an interesting experiment, but do you think Claude can really handle all these edge cases and nuances required to get it right? In my experience AI can write some useful functions, but it rarely gets more complex stuff right in the first shot. On top of that it can frequently drift into a local "minimum", where it repeats the same mistakes over and over and cannot get out without a rewrite by a human 😅.
I guess it could write the general structure and fill it with functions that we know to be working already 🤔.
I'm really curios to see if that actually works ^^.

[stoprocent]

It's pretty much free. If its bad I will learn from it and do it again. Thats the beauty is that the idea and vision is important. Ive been coding for 20 years professionally and almost 30 in total. I know good from bad. Lets see I will make a branch so we can try.

[stoprocent]

Noble isn't really that big

[piranna]

I'm perdonally interested on the experiment, both for the Typescript port (i was already thinking on proposa that, there are some inconsistencies in the exported types, I Hope the new NobleEventEmitter as base class would fix them), and as a 22+ years developer fiddling with almost one-shoot ai code generation :-)

[fquirin]

I found a rather drastic workaround by simply creating a new instance of noble on every poweredOn/Off event.

Unfortunately I realized that even when you completely destroy the 'noble' instance, there is a weird bug that will trigger occasional 'poweredOff' events after an ON-OFF-ON sequence that will kill the scan and require creation of another new instance. I'm not sure if this is a 'noble' bug or simply unpredictable reaction of the adapter to new instances of 'noble' (or a mix of both).
I found a somewhat stable solution for my reworked BLE beacon scanner that keeps throwing errors until power ON is stable again. Obviously that's rather bad for the UX, but it works.

Lets see I will make a branch so we can try.

Considering the scope of a full rewrite, I wonder if a new repository would make sense?
I can do some testing on my Raspberry Pis when you have an alpha or beta version.

[poodle64]

Adding another data point from Docker with a different adapter.

Environment

• Noble via matterjs-server (Matter smart home controller)
• Docker container with network_mode: host, user: "0:0" (root)
• NET_ADMIN + NET_RAW capabilities, apparmor:unconfined
• /run/dbus:/run/dbus:ro mounted
• Host: NixOS, kernel 6.12.63
• Adapter: RTL8851BU USB (USB ID 3625:010b), BT 5.3, firmware via btrtl

Behaviour

Noble reports state: "unknown" on startup and stateChange never fires, despite:

• hciconfig hci0 showing UP RUNNING inside the container
• BlueZ D-Bus query confirming "Powered": true
• The adapter working perfectly with chip-tool (CHIP SDK BLE commissioning) on the same host

The Noble warning is:

noble warning: adapter does not support Bluetooth Low Energy (BLE, Bluetooth Smart).

This is incorrect — the adapter supports BLE 5.3 and works fine outside Noble.

Additional observation

When the BLE adapter is physically removed (USB unplug), Noble's failure to track state also causes the consuming application (matterjs-server) to crash with an unhandled error (Could not start scanning, state is unsupported (not poweredOn)) rather than gracefully handling the adapter disappearance. The stale state means consumers can't distinguish "adapter was never detected" from "adapter was removed."

Impact

This blocks BLE-based Matter device commissioning in Docker for anyone using Noble as the BLE layer. The workaround is to use alternative commissioning tools (chip-tool) that access HCI directly without Noble.

Same root cause as the original report — Noble's HCI state detection doesn't work reliably in Docker containers, regardless of user permissions or adapter hardware.

[poodle64]

We hit this issue running Noble in Docker on NixOS (BlueZ 5.79, kernel 6.12). The HCI user-channel binding requires exclusive adapter access which conflicts with BlueZ, and in Docker the /dev/hciX devices often don't exist at all.

We've built a BlueZ D-Bus binding that resolves this by using org.bluez over the system D-Bus socket instead of raw HCI. State detection uses the Powered property and PropertiesChanged signals — no race conditions, no exclusive access needed, works reliably in Docker with just the D-Bus socket mounted.

Full write-up and the implementation are in #73.