Thanks for the update @halemmerich - that log is really interesting.
TransactionBuilder - Unable to write characteristic: null seems to happen because the characteristic we're writing to (txCharacteristic in BangleJSDeviceSupport) is null. BUT txCharacteristic is only ever written once, in initializeDevice.
So, it seems this doesn't 'just happen'. There is some kind of reconnect, and BangleJSDeviceSupport is torn down and then restarted, but either initializeDevice doesn't get called, or it does but the characteristics didn't get read and so null gets returned.
I've had a quick check and it seems like none of the other watches deal with this eventuality - they all assume that getCharacteristic won't return null too.
But it would explain a lot - there is flow control when sending from Bangle.js to Gadgetbridge, so what happens is Gadgetbridge connects, but never enables notifications on the Bluetooth serial characteristic. After a while the Bangle has sent enough data that its internal buffer gets full, and it sits there just waiting for Gadgetbridge to enable notifications on the characteristic, which it never does.
It looks like initializeDevice is called twice from AbstractBTLEDeviceSupport - once in performInitialized and once in onServicesDiscovered. So maybe if performInitialized gets called and the Bangle isn't connected, we can get in this state where initializeDevice is called before services are discovered?
I could really do with a Gadgetbridge log including the moment things went wrong to be sure
... but this definitely looks like a Gadgetbridge issue now, rather than Bangle.js.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Thanks for the update @halemmerich - that log is really interesting.
TransactionBuilder - Unable to write characteristic: null
seems to happen because the characteristic we're writing to (txCharacteristic in BangleJSDeviceSupport) isnull
. BUT txCharacteristic is only ever written once, ininitializeDevice
.So, it seems this doesn't 'just happen'. There is some kind of reconnect, and BangleJSDeviceSupport is torn down and then restarted, but either
initializeDevice
doesn't get called, or it does but the characteristics didn't get read and sonull
gets returned.I've had a quick check and it seems like none of the other watches deal with this eventuality - they all assume that
getCharacteristic
won't return null too.But it would explain a lot - there is flow control when sending from Bangle.js to Gadgetbridge, so what happens is Gadgetbridge connects, but never enables notifications on the Bluetooth serial characteristic. After a while the Bangle has sent enough data that its internal buffer gets full, and it sits there just waiting for Gadgetbridge to enable notifications on the characteristic, which it never does.
It looks like
initializeDevice
is called twice fromAbstractBTLEDeviceSupport
- once inperformInitialized
and once inonServicesDiscovered
. So maybe ifperformInitialized
gets called and the Bangle isn't connected, we can get in this state whereinitializeDevice
is called before services are discovered?I could really do with a Gadgetbridge log including the moment things went wrong to be sure
... but this definitely looks like a Gadgetbridge issue now, rather than Bangle.js.