Open Apollon77 opened 1 month ago
@Apollon77 that's correct there is no reset ... I've checked and there was never a reset on HCI. There is a reset in the USB implementation and my UART. I will have to review all instances and align functions. Will do it tonight
Yes in fact reset often (always?) gave an error ... so I also removed it from my code :-)
I've added it tho in 1.15.0
. Can you check ?
sorry still crash
hci reset - writing: 01030c00 +0ms
FATAL ERROR: Error::New napi_get_last_error_info
----- Native stack trace -----
1: 0xb822e0 node::OnFatalError(char const*, char const*) [node]
2: 0xc6546c [node]
3: 0xffff98307eb0 Napi::CallbackScope::~CallbackScope() [/home/ingof/official-matter.js/node_modules/@stoprocent/bluetooth-hci-socket/prebuilds/linux-arm64/@stoprocent+bluetooth-hci-socket.armv8.node]
4: 0xffff98308164 Napi::Error::New(napi_env__*) [/home/ingof/official-matter.js/node_modules/@stoprocent/bluetooth-hci-socket/prebuilds/linux-arm64/@stoprocent+bluetooth-hci-socket.armv8.node]
5: 0xffff9830d1cc BluetoothHciSocket::EmitError(Napi::CallbackInfo const&, char const*) [/home/ingof/official-matter.js/node_modules/@stoprocent/bluetooth-hci-socket/prebuilds/linux-arm64/@stoprocent+bluetooth-hci-socket.armv8.node]
6: 0xffff9830f840 BluetoothHciSocket::Write(Napi::CallbackInfo const&) [/home/ingof/official-matter.js/node_modules/@stoprocent/bluetooth-hci-socket/prebuilds/linux-arm64/@stoprocent+bluetooth-hci-socket.armv8.node]
7: 0xffff983106c0 Napi::InstanceWrap<BluetoothHciSocket>::InstanceVoidMethodCallbackWrapper(napi_env__*, napi_callback_info__*) [/home/ingof/official-matter.js/node_modules/@stoprocent/bluetooth-hci-socket/prebuilds/linux-arm64/@stoprocent+bluetooth-hci-socket.armv8.node]
8: 0xc4057c [node]
9: 0xf26e68 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [node]
10: 0xf27628 [node]
11: 0xf27a40 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
12: 0x18a5964 [node]
----- JavaScript stack trace -----
1: Hci.reset (/home/ingof/official-matter.js/node_modules/@stoprocent/noble/lib/hci-socket/hci.js:290:16)
2: NobleBindings.reset (/home/ingof/official-matter.js/node_modules/@stoprocent/noble/lib/hci-socket/bindings.js:86:13)
3: Noble.reset (/home/ingof/official-matter.js/node_modules/@stoprocent/noble/lib/noble.js:193:18)
4: NobleBleClient (/home/ingof/official-matter.js/packages/nodejs-ble/dist/cjs/NobleBleClient.js:52:13)
5: getBleCentralInterface (/home/ingof/official-matter.js/packages/nodejs-ble/dist/cjs/NodeJsBle.js:51:25)
6: configureNetwork (/home/ingof/official-matter.js/packages/matter.js/dist/cjs/CommissioningController.js:435:27)
7: processTicksAndRejections (node:internal/process/task_queues:95:5)
I will have a look tomorrow as I need to use debugger on linux for this one.
all good.I removed rest call for now. rest seems to work. Thank you for all your support
@Apollon77 I had a busy week but I will try tonight to pin point the issue. For now I keep this open
All good. No stress. It is not blocking me for anything.
@Apollon77 The Issue wasn't so much with the reset but with error callbacks. The main thing was that reset was called before binding to the socket. It will now throw a proper JavaScript error when you do this. I think I can add something in @stoprocent/noble
js code not to send hci write
when not opened or you can throw reset in try {...}
Hm, ok but what exactly needs to be done before? the way noble works is that you have this "singleton" and just use startScanning or connect on it ... so reset should also auto bind to the socket when it is not yet, or?
... seems changes in the socket lib
when you call noble.reset()