Where is this battery draining code from?

It shouldn't, no - however if gadgetbridge sent something in response, that could potentially cause a buzz.

So maybe it's sending updates every second when the music is playing showing the current play position, and then somewhere along the line something responds to that when it shouldn't.

It's one of the reasons I gave you that code to run - it would have shown you when and where the buzzing was coming from

I ran that and tried some behaviour that buzzes on Podcast Addict Remote (up/down swipes to change volume) to see if it triggered it. But now I look at it a little closer I don't think that is what it would catch.

I have now uploaded the buzz module to a file on the watch, named it "buzz". Going to start logging on the watch via 'Settings'->'Utils'->'Debug'.

You said earlier:

@Ganblejs Any chance you could connect with the IDE and paste this on the left hand side:

require("Storage").write("buzzdebug.boot.js",'require("buzz").pattern=p=>{throw new Error(`buzz! ${p}`)}');

And then maybe leave it connected to the Web IDE?

Which I can do, but that way there's no way to track if the problem stems from the communication with gadgetbridge? But I think that is solved if I enable logging on the bangle and connect to gadgetbridge instead, right?

Which I can do, but that way there's no way to track if the problem stems from the communication with gadgetbridge?

Well, hopefully you'll get a stack trace which will point straight to the Android app on the watch, which would help a lot - but as you say you wouldn't see that message if you were then connected to Gadgetbridge (unless you used logcat, or use the new 'remote connection' in the Gadgetbridge app loader).

You could definitely try and enable logging and see what happens - there is even logging in Gadgetbridge itself (or you obviously have Android Studio set up so you could look at logcat to see what's being sent).

I think if you're looking at the Gadgetbridge logcat while using Podcast Addict and you're seeing a bunch of data transferred to the Bangle, that could be a good step to see what's going wrong. If you can isolate the GB(...) message that's being sent, we could try running that in the IDE with debugger;GB(...) and trace through exactly what happens.

Ok, thanks for all help! I shall see what I can find out 🙂

Attached is output from to the Web IDE after having had it connected to my bangle for a couple of hours today. Podcast Addict Remote was open on the watch during that time.

The error message from buzzdebug.boot.js didn't trigger during this time.

EDIT:

or use the new 'remote connection' in the Gadgetbridge app loader).

I'll do that next.

1 Attachment

• web-ide-output-looking-for-bug-triggering-buzz-module.txt

or use the new 'remote connection' in the Gadgetbridge app loader).

I tried this once, but for some reason somewhere along the way the watch was disconnected from the web ide where I was checking for the error message. So that time it didn't yield to much.

Tonight I had the battery fall of a cliff once again when Podcast Addict was active (Fastload utils not installed). Unfortunately I only have the gadgetbridge battery graph and nothing else. But I'll try connecting it to the web ide as suggested again.

3 Attachments

I think battery falling like that can only be either a horribly wrong value for the battery calibration (and relatively low charge being shown as full) or GPS being active. There is just no hardware taking that much power besides full power backlight, but I suspect you would have seen that at some point. Do you have agpsdata configured for autoupdating? Maybe there is some bug not turning GPS off after the update.

Do you have agpsdata configured for autoupdating? Maybe there is some bug not turning GPS off after the update.

I don't have it installed now. I did have it installed before I removed it as part of this process some time ago: https://forum.espruino.com/conversations/385629/#16983079

Well, hopefully you'll get a stack trace which will point straight to the Android app on the watch, which would help a lot - but as you say you wouldn't see that message if you were then connected to Gadgetbridge (unless you used logcat, or use the new 'remote connection' in the Gadgetbridge app loader).

Now I've tried twice with this setup:

• Watch is connected to Gadgetbridge.
  
• I use the new remote connection feature of App Loader to get logs/prints to the console in Web IDE. The App Loader is open inside Gadgetbridge.
  
• I have the bootcode you gave me on the watch.
  
• My android device is set up to keep screen on while charging.
  
• My laptop is set up to also keep awake.
  
  

But the connection between App Loader and Web IDE is soon lost.

I'll try this once more I think, or I'll try adding in Android Studios logcat in the mix as suggested as well.

I'll try this once more I think, or I'll try adding in Android Studios logcat in the mix as suggested as well.

I did this again and this time closer to my wifi router, the connection held much better. Also connected the Android Studio logcat.

During the ca 2 hours I had it running now the bug didn't occur though. The buzz module code doesn't show in the Deferred Function Calls table either. Will try again at a later time.

I had some odd issue a week or so ago where my Bangle lost a bunch of charge very quickly (I woke up and found it almost flat and on the messages list screen) and I was pretty sure that in that case the backlight had got stuck on.

So it's definitely worth checking to see if podcast addict keeps the screen on - if it's constantly getting notifications from Gadgetbridge I guess it may well be keeping it on?

During waking hours the other day I noticed the messagesgui was open and didn't time out to the clock face. The screen was locked and lcd backlight off - could be unlocked and backlight turned on with hw button press. My experience was that this state had a high draw of the batter for some reason - even though it feels unwarranted (the watch was just sitting on one of the messages - shouldn't be very battery intensive..).

Hmm, that's an odd one. I just tried here on a power meter, and the power draw when displaying a message was 2.5mA, where normally you'd expect 0.25mA

And actually opening a message then going back to the messages list raised it slightly - by 2.5mA each time! I've just had a look at timers and it would appear to be something related to the buzz pattern, which we have seen in logs before. I'll try and have a look at it later tonight - it's good I can reproduce

Fixed it! https://github.com/espruino/BangleApps/commit/2b6f7765cc69db5e8dd34fa9ad86051914e26601

If you update messages now it should pull in the new buzz, which will fix the power draw at least for the messages app. I'm not sure if it'll help with podcast remote, but it may

Nice, will do - thanks!

Actually I don't think podcast addict remote utilizes the buzz module. I suspect it has been messagesgui all along, if that makes sense. But I'll see.

If you're fastloading apps it would have made the problem miles worse as well - just because the timeouts would keep piling up.

... and all because I forgot a return!

I haven't used fastload utils in a while now.

I think I remember messages will buzz 'under' podcast addict remote, but not display messagesgui (I haven't disabled auto-open). And I think this happens whether I have fastload utils installed or not.

But don't read too much into this, it's not fresh in my mind.

Edit: But I get the feeling this might be the expected behaviour and auto-open should only happen on a clock face.

I get the feeling this might be the expected behaviour and auto-open should only happen on a clock face.

Yes, I think that's right