[Bangle.js 2] Seemingly random freezes / unresponsive?

So you still managed to reconnect via GB while the watchface was stil frozen? What FW version you have?

In my case the battery lasted several days while being stuck. At least when attaching charger after few days it still only charged and did not boot from cold state so battery was not dead. When CPU is stuck in a loop it should die in a day or two. Also I could never reconnect in the frozen state.

Anyway, I have updated mine to latest version few days ago and waiting for the freeze to happen again.

(previous message)

I have noticed a hanging watchface today, stuck on 18:41. Last value for battery in GB is 15:11 (100%). I have powermanager with monotic voltage/percentage settings active, so quite possible there was no change in reported battery between 15:11 and 18:41. Next battery value is 56% at 20:48, so quite a big drop. Maybe something going into an endless loop, eating cpu cycles?

Watch was still connected to GB at 20:48. I saved two GB logs, one 20:48 before reconnecting and one 20:50 after reconnecting. Both logs are identical save the additional lines in the one saved later.
It starts at 19:13, so the moment of freezing was not captured, but there are a whole lot of

19:13:32.816 [main] WARN  n.f.g.s.b.TransactionBuilder - Unable to write characteristic: null

lines.

First log stops at 20:47:33.853, so definitely still hanging then, reconnect in GB reviving the Bangle shortly after that. Sadly nothing obvious (at least to me) in the logs. Saving the debug logs did not actually store the logs. I am using the fdroid version of the app.
I have attached a log with private info replaced by placeholders.

Edit: Not a percent of battery lost in the last hour, so hanging actually does something expensive in terms of power use on the watch.

Yes, did not touch the bangle after noticing the freeze. Disconnecting and reconnecting in GB usually brings it back, holding the button for full reboot works as well. I'm on 2v16.7 currently. I had some hangs that could not be solved by reconnecting in GB, but have not seen one of those for months.

1 Attachment

• eabc77ff8ce10a252e0b43970ba8515f01d00dde.log

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.

I get occasional hangs when using Settings menu's. I'm on 2.16.7 firmware and everything else 100% up to date. I dont use GadgetBridge atm.

I have captured another log. Clock was frozen at 11:41 and log goes back to 9:10.
First Unable to notify characteristic: null at 11:10:22:934
Manual reconnect in GB at about 12:44.

1 Attachment

• gb2.log

Small update: Have not connected the Bangle to GB since saturday morning, no freezes since then and significantly lower battery use.

That's great, thanks for that! And good removal of sensitive info ;)

I filed an issue with Gadgetbridge here asking for the correct way to go about fixing this: https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2996

But I'd be pretty sure we know what the issue is now. It's just how to force a disconnect + reconnect nicely.

Sorry to poke such an old thread but I'm currently experiencing this issue and was just wondering if there's any more progress with a fix, or a good workaround?

What Bangle.js firmware version number do you have on the watch?

What Gadgetbridge version and version number do you use on your phone, if it's an Android one?

Are your apps on the watch up to date?

hi,
for me on latest GB.js and firmware,
today is the 2nd time (in this 2 months) that somehow the pattern launcher AND "swipe back to clock" seems wont work, even after re-install, so i have to format(=factory reset) it again.

to me, it seems it happened after i changed the fontsize back to 18? i am not sure.

may be could play with that later when i am in the gym, thanks

update 231119T014901,
it happened again within 2hr, while i factory reset the bangle and re-install everything again.
the pattern launcher + swipe back to clock did n't work again, after i try to send a sms(/w chinese) to phone and pass to bangle.

may be the pattern launcher is too heavy?
i'll try use bangle without the pattern launcher and see.

however without pattern launcher, the bangle cant prevent access from anybody (although pattern launcher only provide partial). would be nice if later bangle could have build in pattern lock or PIN lock? like android etc.

thanks

Watch firmware: 2v19, DFU 2v16
Android Bangle.js Gadgetbridge Version: 0.76.1a-banglejs
Apps up to date as of 2 weeks ago updating again now (should have done that first, sorry, but this issue has been going on through multiple updates for many months).
settings .65->.68, alarms .44->.45, weather .25->.26, message ui .74->.75

As folks above have said, manually disconnecting/reconnecting through GB on the phone or rebooting the watch fixes it but the watch freezes and remains unresponsive on a frozen watch face until then.

Deleted.

It freezes on both "Weather Clock" and "Mountain Pass Clock" faces, I haven't noticed it in other apps but I don't leave them up and idling for meaningful amounts of time. Attached is filtered logcat dump of all gadgetbridge tagged entries in the minute it froze at 19:19 yesterday if that helps.

1 Attachment

• logcat_froze_at_1919.log

Thanks for the log - that really helps to narrow it down. So this appears to be https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2996 again - I thought that had maybe sorted itself out.

I've just pushed a change to Gadgetbridge to attempt to fix it - but it's a hard one to know for sure as we can't reliably reproduce it while on a debugger (and I think it might depend on your phone/OS). So if you install the nightly build of Gadgetbridge tomorrow, I hope you won't end up seeing it again :)

Awesome, I will look into getting that installed and let you know how it works out. It usually happens to me 1-2 times per day so I'll check back in a few days to a week if it's all clear. Thank you so much!

edit: a couple days in and it's working great so far!

err...

some of my reporting, gpt4 summarized:
I switched from "pattern launcher" to "quick launcher" on my device, and it functioned correctly yesterday. However, after installing the msg UI today, I encountered problems with both "quick launcher" and "swipe back to clock" app, they simply dont work, which persisted even after reinstalling the app. Consequently, I reverted to using "pattern launcher" and installed msg list and msg lib, but not msg UI, and this setup seems to be working well. Since my bangle is now functioning effectively, including controlling music with Chinese names, I've decided not to make any further modifications and expect to avoid any further issues.