meshtastic
[Bug]: 2.6.33 - 2.7 + Phone battery drain
What happened?
Noticing excessive battery drain since 2.6.33. can only measure it by saying phone (pixel 7) has hit 20% warning each night since update. See screenshot. Did not occur on previous versions.
App Version
2.6.33
Phone
Pixel 7, Android 15 latest update.
Device
T1000e
Firmware
2.6.11
Relevant log output
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Can you roll back and get a comparison?
I'd say the BT issues are likely to blame, but it would be good to confirm that this is real, not just a perception.
Does not happen on 2.6.30. Half the battery usage with similar same screen and background use compared to 2.6.33.
I've had it since 2.6.32. And now with 34. With both BT and WiFi connection.
As a workaround, I've disabled background run in Android settings for the app.
Updated to 2.7.1 directly from 2.6.3. Battery drain went very high. Had to sideload back to 2.6.3 and can verify it fixed battery drain issue.
I have the issue in 2.7.0 and 2.7.1, it is consuming excessive battery when I leave the app connected to a Bluetooth node. Workaround is to disconnect from the node and only reconnect when I'm checking messages.
Same here on a Fairphone 5. Has been great with battery life until Meshtastic app update. Also the node list seems really sluggish from time to time, could be related?
Edit: version 2.7.2 by the way
@mjvolante - curious why you closed this as completed? was there a fix for this? i am also having same problem.
I can second that the issue is still present (and still super annoying) in version 2.7.3. @mjvolante is there a fix coming in an upcoming release? Or did you close the issue accidentally? Or is it a duplicate? Please clarify for us ignorant mortals :)
I have the same problem (2.7.3) I don't know if it is related, but the GPS usage is wild, for example in the detailed information about battery usage, I see 3h53 hours of GPS use in the last 5h18 (when I unplugged my phone from its charger). The app is connected to one node (using wifi) which has a fixed position/no gps. The app was not opened once during these last 5h18.
I can confirm that after removing the GPS authorization to the Meshtastic app, the battery drain has gone. After 5 hours the app doesn't even appear in the battery usage of my Samsung S20+.
Good find.
Now we might be able to action this ticket.
Have you ever shared GPS to the app? Is it currently? If you give it the permissions back, then toggle it on the app, does that make any impact at all?
When I installed the app I gave it precise GPS location access.
I have used the GPS function on the map page (to center the map on my location) but I think that's all. I have never configured a node to specifically use the phone GPS instead of its set position. The app was only associated with:
- my T3S3 configured with fixed position
- a t-deck for a small amount of time to configure settings like the timezone. But it is supposed to use its own gps.
I'll try to give the app the different positionning possibilities (accurate using GPS / not precise using 4G relays antennas and not GPS) and report back. But only one setting per day to really understand. I'll report back in a few days
Hi, I've also encountered exact same issue, with following items/versions:
- Pixel 7a / Android 16 (BP3A.251005.004.B1)
- Meshtastic App / 2.7.3 (29319219 google)
- Seeed Studio T1000-E Meshtastic / 2.6.11.60ec05e
- Both MQTT&GPS proxied from phone, GPS was set to Smart Position
I have confirmed following as of now:
- App's battery usage by GPS is significantly high, more than MQTT proxy
- When app's location permission is changed to non precise, drain is reduced but still exists
- Revoking location permission entiery also stops battery drain
- T1000-E's battery isn't much drained as far as I've checked so far, not entirely sure as it's just arrived today
My hunch is not only GPS handilng itself, but also Smart Position, which I forgot to turn off when setting up T1000-E. So, I disabled Smart Position and permit app's location to precise again just now, and see if how it goes from now on.
Quick sitrep after half a day after i disabled Smart Position.
On precise location shared from phone to node while Smart Position disabled, battery usage on standby is reduced significantly.
Since I haven't disabled MQTT proxy, some background usage were observed as excepted.
I'm not sure GPS interval setting on node will affect the phone side's GPS, but sounds likely to so, as node will request the phone for the location with this interval, making app's usage higher.
That's as far as I can report, hope @spfmoby and others may provide more precise reports, thanks in advance!
While I'll test some more today, with MQTT proxy disabled.
Thanks t-miura,
at some point can you format your testing in a table (github uses markdown ) to make it a bit easier to parse once someone has a chance to get to this one.
include app version, settings, and your results and conclusions. and anything else you think is relevent
Here is my update:
What doesn't change: Node: Lilygo T3S3 Meshtastic version of the node: 2.7.10 Link with the smartphone: wifi
Phone: Samsung S20+ / Android 13 Meshtastic android app version: 2.7.3
Channels settings: Position: enabled / Precise location: disabled / 299ft precision Position settings: Smart position: disabled / Fixed position: enabled MQTT: enabled / Map reporting: enabled
Tests: In the phone app permissions:
- Location permission: off -> no drain. If unoppened (no screen time), the app does not appear in the battery usage of the phone
- Location permission: not precise -> no drain. Same as above
- Location permission: precise -> huge drain, around 30% per 24 hours, even if I don't even open the app during those 24 hours.
I too have disabled the location permission and my first test today seems to indicate that this solves the issue.
Meshtastic went from absolute king in battery usage to app number three in the list, with a reasonable usage for an app that has a bluetooth connection all day.
The weird thing is that I'm connecting to a T1000-E, which has its own gps radio. I don't even think I had the phone location sharing feature turned on (it is not on right now), and even if I did I would expect it to ignore the setting and use the node's gps..?
Edit: ran with the location permission revoked for a couple of days now. Issue seems to have disappeared. If you need more information or for me to test an alpha version of the app, let me know.
Same here. Pixel 7a, app version 2.7.5 (29319286), connecting via Bluetooth to T1000-e.
Had to force close it last night because it was using ~300% CPU and melting my phone. 2.7.5 with t1000e
@DaneEvans sorry for late reply, i'll try to gather data once again as it looks it got new build, with any relevant data, may take some days or so.
meanwhile, recent comments from others has one common point: all using Seeed T1000-E, and indeed me too. however @spfmoby is using T3S3 and having same issue, so i think it's not node-dependent issue.
I also have T-Deck Plus, which can be also used on same phone to see if it makes any difference.
Perfect, we'd much rather be working on current data anyway. Ping me when you drop the data in
I experienced the same problem, on a Samsung Android tablet and a Samsung smartphone - Note that I never have the GPS activated on my android devices
Affected app version 2.7.7
Affected Android version Android 10, Android 15
Affected phone model Samsung Galaxy S9+ (but certainly most of them), Galaxy Tab A9+
Affected node model rak4631, wismesh tag, and others
Affected node firmware version 2.7.15
- Foreground: 1 h 30 min
- Background: 10 h 54 min → 31 % of total battery consumed (that's isane!)
I only discovered this days later when my phone was dying far faster than normal and I finally checked the per-app breakdown. I knew I was using the phone a little bit more but come on.
Bluetooth earbuds for hours with music, doesn't draw that much.
Even if a large part of that 31 % were wrongly attributed to the short foreground time, it would still be completely unacceptable... no messaging or Bluetooth app behaves like this honestly.
This single issue makes the app unusable for all-day field use (hiking, SOTA, emergency) on older but still very common devices like the S9+.
Please prioritize a proper fix.... inactivity-based Bluetooth disconnect with packet queuing, significantly reduced polling intervals, and full compatibility with Android power-saving features (if it's not there) or anything that would make these things really "off-grid".
I mean, if the main device is constantly dying and wet can't connect to meshtastic, off grid.
This should be a priority, it's pretty much what mesthastic is for
Thank you :)
Here on a tablet.
Youtube playing music and with the screen on, sometimes off. Pulling 3gb of data on wifi constantly.
But add the background drain for the app, in comparison of an app like youtube, there is no contest here. The meshtastic app is killing batteries.
I never had to charge my tablet and my phone more than twice a day for a regular use, with Bluetooth activated, music, youtube, etc., I really thought my battery was dying, but no it correspond to when I installed the app and started to use meshtastic.
Today, without even using the app (I checked, we got just 4 messages received all night on a meshtastic node)
24%, and the day just started. Omg, I didn't realized how much battery is gone during the night.
I too have disabled the location permission and my first test today seems to indicate that this solves the issue.
Meshtastic went from absolute king in battery usage to app number three in the list, with a reasonable usage for an app that has a bluetooth connection all day.
The weird thing is that I'm connecting to a T1000-E, which has its own gps radio. I don't even think I had the phone location sharing feature turned on (it is not on right now), and even if I did I would expect it to ignore the setting and use the node's gps..?
Edit: ran with the location permission revoked for a couple of days now. Issue seems to have disappeared. If you need more information or for me to test an alpha version of the app, let me know.
I mean, the app is unusable without the location permission because it asks for this permission for the Bluetooth connection to a node...
Please folk, tables with summaries. Preferably for the whole thread. 5 Screenshots that take up an entire monitor each are hard to decipher.
If I have to go through this whole thing to look for patterns it'll be 4 hours of dev time that could be spent doing 2 other well defined bugs. And that's before even getting to any actual work. If you want prioritising of issues, then do the non-technical legwork for us.
@neopiccolorat - double check the Meshtastic settings cog > scroll down > App section > provide phone location. It should be off.
I suspect what they were doing is turning off permissions for the phone, not the app: You also should be able to turn gps off on your phone (android top bar/swipe> more > edit pencil > scroll down past the hold & drag to add ... > Location )
@neopiccolorat - double check the Meshtastic settings cog > scroll down > App section > provide phone location. It should be off.
Yep it's off (I never turned it on). Same thing for the location/gps on my smartphone or tablet, I never have them activated and all location permission for all my apps are removed.
Note that the battery usage of the Meshtastic app is not at 38%, with 12h14 as a "background process", and 1h47 active (that's how little I used it today)
I'm pretty sad to have to completely force-close the app to be able to use the phone without having to charge it :/ And I have the "put app to sleep" activated (put this app to sleep immediately when it's not in use). But then, what is "not in use" for the phone in this context. No background process? Or not opened and "used" by the user. But it doesn't seem to do much.
I'm gonna let it go until it goes to 10% battery left to have a new "final" graph.
BTW, a proper bug fix for the ESP32 Wi-Fi connectivity issues I see a lot for awhile would help a ton. I've tested this myself.
Connecting to a node over its IP (from the Android app) barely uses any battery at all in comparison of with Bluetooth, which absolutely drains it for no practical reasons. So many more heavier apps that streams a ton of data don't have this problem. It's a code optimization problem.
So it’d be awesome to prioritize optimizing the Bluetooth side, make it sip as little power as possible just for sending/receiving messages. Looking at the screenshots (not only here but on other forums too), it's pretty clear the current Bluetooth implementation is rough, and that's a real problem for a network that "can" be used for "off-grid" when needed.
Emergency situation, the less need of electricity is the better.
Honestly, both things should get love because together they'd solve like 90% of the complaints:
- Fix Wi-Fi stability on the ESP32 nodes
- Optimize Bluetooth power consumption
Honestly, being able to connect to a node that's on the home LAN, from anywhere in the house, over Wi-Fi using its IP, is waaaaay more practical and useful than Bluetooth. The range alone makes it a no-brainer.
So yeah, Wi-Fi fixes + Bluetooth power improvements would be good.
Thanks
I'm unable to reproduce.
I certainly don't need comments like the above telling me to "fix it" without providing much to go on.
I need the following information:
- Phone model
- Android version
- Firmware version
- Affected devices
- Are you sending GPS to the device: (yes/no)
Nice to have:
- Logs
Please don't dump useless paragraphs, short and sweet is much easier to parse.
https://github.com/meshtastic/Meshtastic-Android/issues/2659#issuecomment-3580823894
sorry again for long blank, i couldn't have enough time to test with stationary setup(and spare node to test with) 🙇 maybe from tomorrow, i can do a test with current non-beta app and report back with you and all in here with table.
Question, could it be not the bluetooth only but device like nr52 (rak4631), have a problem with the MQTT proxy client when enabled? (which doesn't work, I tested it)
see below, a basic mosquitto MQTT server log of a rak19007 + rak4631, with the proxy client enabled, it loops every second, can't connect. So if it does the same on the mqtt.meshtastic.org server, it would be a problem right? (I just anonymized the logs here)
1764950652: New connection from <IP_ADDRESS>:45525 on port 1883. 1764950652: New client connected from <IP_ADDRESS>:45525 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950653: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950653: New connection from <IP_ADDRESS>:45526 on port 1883. 1764950654: New client connected from <IP_ADDRESS>:45526 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950654: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950655: New connection from <IP_ADDRESS>:45527 on port 1883. 1764950655: New client connected from <IP_ADDRESS>:45527 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950656: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950656: New connection from <IP_ADDRESS>:45528 on port 1883. 1764950657: New client connected from <IP_ADDRESS>:45528 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950657: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950658: New connection from <IP_ADDRESS>:45529 on port 1883. 1764950658: New client connected from <IP_ADDRESS>:45529 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950658: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950659: New connection from <IP_ADDRESS>:45530 on port 1883. 1764950659: New client connected from <IP_ADDRESS>:45530 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950660: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection. 1764950660: New connection from <IP_ADDRESS>:45531 on port 1883. 1764950661: New client connected from <IP_ADDRESS>:45531 as MeshtasticAndroidMqttProxy-<CLIENT_ID> (p2, c1, k60, u'<USERNAME>'). 1764950661: Client MeshtasticAndroidMqttProxy-<CLIENT_ID> closed its connection.