android
android copied to clipboard
home-assistant
High battery consumption in flight mode
Home Assistant Android app version(s): beta-9876-e592c334-full
Android version(s): 13, (4.19.87?)
Device model(s): Samsung s20
Home Assistant version: 2023.4.1
Last working Home Assistant release (if known):
Description of problem, include YAML if issue is related to notifications: For the last month or three I can no longer set my phone to flight mode at night, since it will drain the battery almost completely if the phone is not fully charged. (Although the battery drain isnt exactly predictable).
Earlier the phone has lost only a few percent during the night, but now, it seems to loose ~30-60% instead. The only app that changes its battery usage drastically during the night, is the HA app.
Companion App Logs: I'll update ticket with logs from next night.
Screenshot or video of problem:
Before : 
After:
Additional information: I havent tested it often/properly, but it seems that it helps to close all "recent applications". But then, since I have HA widgets on my home-screen, and background access, I assume the app is triggered fairly automatically/continuously.
Check these points
https://companion.home-assistant.io/docs/troubleshooting/faqs#android-app-battery-drain
Is this an automated response for battery tickets, since it doesnt seem to read the issue.
Its in FLIGHT MODE! Are you telling me that I should change the settings for persistent connection or sensor updates, whenever I set my phone to flight mode??!
When there is no network connection, the applications should DISABLE its attempts to reach the network, instead of spending time using battery for no purpose. Even the facebook app seems to manage it...
Is this an automated response for battery tickets, since it doesnt seem to read the issue.
These are steps given to any user who has a battery drain issue.
Its in FLIGHT MODE! Are you telling me that I should change the settings for persistent connection or sensor updates, whenever I set my phone to flight mode??!
Persistent connection actually ignores flight mode setting as a user can have Wifi enabled with airplane mode on and you do not need a data connection for the persistent connection to work. It is also designed to keep trying to maintain a connection until its established, otherwise notifications will be severely delayed. We don't know if that is happening here as we have yet to see the logs.
What other troubleshooting steps have you tried? Have you tried starting fresh?
Personally I cannot reproduce the issue so starting fresh will probably help.
Hi, for information, I also cet this issue on 2 phones (android 12 with grapheneos, lineageos 18) singe last android update (big battery consumption with airplane mode). I will try a starting fresh to see if it solve it.
Sure, its good that there is a workaround, but this is STILL a bug. Trying to export the app log this morning (during a night when the phone went from 84 to 17 % during the night), makes the app crash continously.
I wouldn't call it a work around. Sometimes bad data does occur and starting fresh can clear it up. There is a reason why those steps exist.
We need the crash log in order to continue on that error. If you see a Recent Crash tab in the log screen we would need, there is no guarantee the app can save the last crash. You can use either Android studio or an app like logcat reader to pull the crash however that is probably a separate issue from this.
I dont agree. Yes, bad data occurs. And a working app will detect that bad data, and will not run around in an endless loop consuming battery for no reason. An app that does that, has a bug. Whatever the reason. Whatever old data is lying around, that shouldnt, and that causes the app to perform badly, should be ignored.
I'm perfectly fine with the fact that these errors occur, and that maybe I have to follow the reset/fresh mechanism. But that doesnt change the fact that the app is misbehaving, and should be able to detect the missing network connection, and stop trying to use it (or whatever its doing, that consumes battery)
I will continue to try and extract a log.
I will continue to try and extract a log.
Yes please get us the logs. If possible try to make sure the logs are about 10 minutes or longer so we can look at the various communication going. we have a lot of debug logs which should hopefully indicate what the issue is.
Hi, I have a similar problem since the update on F-Droid; see below for soft/hardware details.
The battery went from 80% to 50% in 8 hours in airplane mode and the battery manager clearly blames the application.
Here are the logs, (adb logcat | grep homeassistant).
I killed the application at 16:12 as you can see.
The log doesn't go earlier than 15:00 but many messages are obviously repeated:
04-13 14:59:46.350 1443 1472 D ConnectivityService: requestNetwork for uid/pid:10351/20029 NetworkRequest [ TRACK_DEFAULT id=49830, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED Uid: 10351 AdministratorUids: [] RequestorUid: 10351 RequestorPackageName: io.homeassistant.companion.android.minimal] ]
04-13 14:59:46.475 1443 1693 D ConnectivityService: releasing NetworkRequest [ TRACK_DEFAULT id=49830, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED Uid: 10351 AdministratorUids: [] RequestorUid: 10351 RequestorPackageName: io.homeassistant.companion.android.minimal] ] (release request)
-
Home Assistant Android app version(s): From 2023.1.1-minimal to 2023.3.0-minimal
-
Android version(s): 11
-
Device model(s): Redmi
-
Home Assistant version: Home Assistant Core 2022.5.5 GUI version : 20220504.1 - latest
-
logcat: homeassistant_dump.log.tar.gz
A got a log but....but I gave up trying to get the log in the morning after a full night of flightmode (because the app crashed when trying to open the log), so this time I forcefully terminated the app when I when to bed. (Which kept the battery from 42->38, instead of the usual of loosing at least 50% battery). Although, the app seems to have awakened anyway, without the bug appearing, maybe because of my widgets?
Then, after starting everything in the morning, I turned on flightmode again at 06.24, and let it sit until 06:28-isch. So, I dont know if the log contains the actual error, but all my other attempts of getting a log so far, have failed. There are at least some nice java crashes in there :-)
04-14 06:24:29.754 13010 13449 E PhoneStateSM: java.lang.NullPointerException: info.carrierName must not be null
homeassistant_companion_log_3-14-2023_6-29-15.txt
@TheQue42 So there is already an interesting bit of the logs that shouldnt be an issue but seems to be an issue with an internal file. Just mentioning it since its an odd error and these files are not in the app control. So its weird that its expecting something to be there that is not.
04-13 22:03:21.521 13010 13010 W ziparchive: Unable to open '/data/app/~~8LpWDggLLGxZSe9ZyZOcdg==/io.homeassistant.companion.android-fJkBjayAvRj8WQ0dDVCvGw==/split_config.arm64_v8a.dm': No such file or directory
I see this failure repeated for a few files. Just to confirm you did not follow the start fresh steps yet correct? Normally I would not expect to see an error like this
04-13 22:03:21.653 13010 13048 W ziparchive: Unable to open '/data/app/~~dBqdazq0C8uEvszjdZ9HJA==/com.google.android.trichromelibrary_556311634-WNZWUFfQdeivW31gqyeMYw==/base.dm': No such file or directory
The phone error you mention is safe to ignore, its a handled exception.
I dont see anything in the logs that would indicate battery draining. Sensor updates happen as expected and fail as expected and they are not occurring in a high number.
Here are the logs, (adb logcat | grep homeassistant).
@ysard Unfortunately this will not show the whole set of logs from the application, you should use the in the app log reader to pull all the logs generated by the app.
@dshokouhi, ok I should have filtered on PID :p
Here is a log from the app, i think you will see a pattern :p Same context: -30% of battery level in flight mode during ~8hours; app was killed at 15:40. The phone was quite hot. I have no log before 15:36, but there is the same error repeated ~127 times in ~20 seconds.
04-15 15:36:54.062 13320 13320 I WM-SystemFgDispatcher: Started foreground service Intent { act=ACTION_START_FOREGROUND cmp=io.homeassistant.companion.android.minimal/androidx.work.impl.foreground.SystemForegroundService (has extras) }
04-15 15:36:54.070 13320 26357 D SensorWorker: Updating all Sensors in foreground.
04-15 15:36:54.075 13320 26357 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: false
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: Work [ id=fc7d7607-e0f1-4ce6-9ffd-6a4c75c24719, tags={ io.homeassistant.companion.android.sensors.SensorWorker } ] was cancelled
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: java.util.concurrent.CancellationException: Task was cancelled.
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1184)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:514)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:475)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:317)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
04-15 15:36:54.076 13320 19031 I WM-WorkerWrapper: at java.lang.Thread.run(Thread.java:923)
04-15 15:36:54.291 13320 26316 E SensorReceiver: Exception while awaiting sensor updates.
04-15 15:36:54.291 13320 26316 E SensorReceiver: kotlinx.coroutines.JobCancellationException: Job was cancelled; job=JobImpl{Cancelling}@f938930
04-15 15:36:54.294 13320 26316 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: false
04-15 15:36:54.386 13320 19044 I WM-Processor: Moving WorkSpec (fc7d7607-e0f1-4ce6-9ffd-6a4c75c24719) to the foreground
@ysard your logs are only 2 minutes long. The cancellation error messages are safe to ignore. There is nothing obvious about what is causing the work manager to start up but its cancelling because our job constraint is not met due to lack of connection.
I think it might be time for you guys to join the other user in trying the start fresh steps to see how reproducible the issue is. If the issue comes back immediately then that would lead to more troubleshooting. However if it does not come back then that would indeed suggest something just needed to be cleaned up.
I've got sick children at home currently, so I havent go time to figure out how to proceed with adb/logcat, but I'll add a longer long here anyway, just in case it adds something. I'll try to figure out the logcat stuff during the week. homeassistant_companion_log_3-16-2023_13-51-11.txt
I still do not see anything that would lead to extra battery drain. At this point I think the next steps are to follow the start fresh steps to see just how reproducible the issue is. Those steps are designed to start things with a clean slate and if the issue is reproducible it should appear again the next time flight mode is kicked in. If the issue is no longer reproducible then the steps were correct to follow.
https://companion.home-assistant.io/docs/troubleshooting/faqs/#starting-fresh-with-the-android-app
If that was directed at me, I simply dont understand the logic of this.
It is a fact that the app causes battery drain. At least if the battery consumption monitor in android is something I can trust.
The restart-refresh does not SOLVE the bug. It might remove the preconditions of the bug, but the code that causes the error, will still be there. Unless your saying that there is cached, executable code that will be cleaned away by a reset/restart(?), then the faulty code, that starts "looping" in some way because of the faulty data, will still be there, and that code should detect the faulty data, and at the very least, ignore it, or even better, delete and/or correct it.
As a troubleshooter for 20+ years, I cant understand why your go-to solution, isn't focused on figuring out why the application behaves badly. I can live with this error, since my workaround is simply to forcefully terminate the app after enabling flightmode. If I do that, my battery drag will be in the single percent, for the whole night.
If there is a bug in the code then the issue will be reproducible. If you follow those steps and you come back and say the issue is still there then that will speak to how reproducible the issue so we can fix the bug. If we can reproduce the issue then we can fix the bug and as of now we cannot reproduce the issue. The logs provided did not indicate anything was draining the battery. As part of troubleshooting after looking at the logs yes you may be asked to start fresh and see if the issue is still there, that is why those steps exist and why we ask users to perform the steps.
I love Java: generating more than 6 unhandled exceptions per second is still considered normal for an application :D
Troll aside, the problem is still there with the same findings.
What I did:
- Uninstalled the 2023.3.0-minimal application
- Installed version 2023.1.1-minimal
- Configured this application (see below)
- Installed version 2023.3.0-minimal
After reading that you asked for a reset of the cache and data of the application:
- Cleared the cache and data
- Configured the application at the next start (see below)
Configuration of the app:
- At the first startup, skip the notification configuration screen
- Click on the URL of the HA instance that appears on the local network
- Configure the login
- Nothing more (the interface connects and updates).
I never touched anything else in the settings of this application. This procedure had to be repeated at each re-installation mentioned above.
Use cases
Below, some use cases, showing in my opinion that the behavior of the application in case of network failure has changed between the 2 versions.
The battery drain problem does not seem to be instantaneous, I have noticed that that it takes several hours for the phone to become hot.
I provide another dump, captured a priori more recently after the triggering of the problem (version 2023.3.0-minimal). It would be necessary to put the phone on logcat for 12 hours which is hardly achievable for me.
One temporary solution is to kill the app when not used or to refuse battery usage on background...
I know that a lot of code has changed between these 2 versions, with the refactoring due to multiserver support. I hope this will put you on a track.
Version 2023.1.1-minimal:
- Wifi enabled,
- Opening HA application
- Opening of the screen of the list of the services in execution 1 process, 0 service that disappears quickly (< 3 seconds) because of the change of activity on the screen
- Wifi disabled
- Removal of the application from the recently used applications
- Display of the list of services Nothing
- Activate wifi Nothing
- Removal of the application from the recently used applications
- Disable wifi
- Start the application
- Display of the list of services 1 process present, briefly
- Wifi activation 2 processes, 1 service that remain 15 seconds
Version 2023.3.0-minimal:
- Wifi enabled,
- Open HA application
- Opening of the screen of the list of the services in execution 1 process, 0 service that disappears quickly (< 3 seconds) because of the change of activity on the screen
- Wifi enabled,
- Open HA app
- Wifi disabled
- Opening the list of running services screen 1 process, 0 service disappears quickly (< 3 seconds) because of the change of activity on the screen
- Return to the application in the list of recent applications the app signals a connection loss, there is a notification "updating sensors" that remains
- Display of the list of services 2 processes, 1 service that persist without end with a notification "updating sensors" which remains
- Wifi disabled
- Open HA application
- Removal of the application from the recently used applications
- Display of the list of services 2 processes, 1 service that persist endlessly with a notification "updating sensors" which remains => removing the application from the list of recent applications is not enough, it must be killed
- Wifi disabled
- Open HA application
- Remove the application from the list of recently used applications
- Display of the list of services 2 processes, 1 service that persist endlessly with a notification "updating sensors" which remains
- Wifi activation
- back to the application the notification disappears only at this moment
- Opening of the screen of the list of the services in execution 1 process, 0 service that disappears quickly (< 3 seconds) because of the change of activity on the screen
- Removal of the application from the recently used applications
- Disable wifi
- Start of the application
- Display of the list of services 2 processes, 1 service that persist endlessly
- Wifi activation The application closes correctly after a variable time (5-20 seconds). The notification of the sensors update disappears.
Logs:
Maybe testing several times a second if a network connection is available or if the sensors can update themselves is excessive and that there is a way to delay these routines.
For 27 minutes of recording:
$ grep -in -R "SensorReceiver: Exception while awaiting sensor updates" ./* | cut -d ":" -f 1 | uniq -c
5097 ./dump3.log
$ grep -in -R "Connection reset" ./* | cut -d ":" -f 1 | uniq -c
378 ./dump3.log
Dump
I love Java: generating more than 6 unhandled exceptions per second is still considered normal for an application :D
This is an incorrect statement. The exceptions are indeed handled as the application is not crashing. They are also safe to ignore as its a cancellation exception generated by Android WorkManager API.
- Wifi enabled,
- Open HA app
- Wifi disabled
- Opening the list of running services screen 1 process, 0 service disappears quickly (< 3 seconds) because of the change of activity on the screen
- Return to the application in the list of recent applications the app signals a connection loss, there is a notification "updating sensors" that remains
- Display of the list of services 2 processes, 1 service that persist without end with a notification "updating sensors" which remains
The updating sensors notification that is remaining is safe to ignore and does not drain battery. I have 4 servers here and 2 of which are dev servers that are always offline. I do also see the notification there from time to time but I experience no extra drain.
- => removing the application from the list of recent applications is not enough, it must be killed
This behavior will vary from device to device. Removing an application from recents does not necessarily mean the app will be force stopped.
The battery drain problem does not seem to be instantaneous, I have noticed that that it takes several hours for the phone to become hot.
Then this means that the logs generated probably do not contain what we are looking for.
Maybe testing several times a second if a network connection is available or if the sensors can update themselves is excessive and that there is a way to delay these routines.
There are job constraints put in place to prevent the network calls when not connected. We also are not the ones scheduling those frequent jobs. Our WorkMaanager job is on a 15 minute schedule. Everything else are intents fired by the android OS sent to the app. I have every sensor enabled sending to 4 server and 2 of which are always offline and I see 0 extra drain. So even if you see attempts that constantly and consistently fail it is not the cause of extra drain.
Adding my voice to this as it's also driving me mad and just came across this while searching, after I narrowed down the issue to the Home Assistant Android App (mine is the F-Droid variant, if that matters).
I forgot when it started (more than several weeks ago). I put my phone in aeroplane mode each night, have done for a long as I can remember, and noticed the battery dropping at an alarming rate - anywhere between 20% to running down flat - with the battery usage only showing "Phone Idle" as the culprit.
I removed apps in batches until I narrowed it down to Home Assistant.
If I go into the app info and set it to "Disabled" overnight, I barely lose any battery, maybe 2% before the morning.
I've not yet tried installing older versions from F-Droid (to see when it broke) as that'll take some time to test each one over night, but that would be my next step unless anyone has any other ideas.
The constant server connection is set to "never" too.
I can also see an "Updating Sensors" notification in the morning when this started, which is a new thing to me.
I can confirm the issue with battery drain in flight mode. I am using the beta 9996-57024e15-full with Redmi K20pro (Android 11). I think the issue isn't in the last stable release (2023.3.0)
Can confirm it still exists, 2023.6.0-full just used 48% of battery in 2 hours with flight mode, on a Pixel 7. It used ~4% during the hours before turning on flight mode.
I'm glad people are still following this. I've had to remove the app from my phone due to this issue - I can still access the dashboard from the web browser, but all my mobile-based automations are now dead. Bums me out. I know us "Flight Mode-rs" are a tiny fraction of the user base, but it still stings.
just to leave a comment here, I went on a cruise in May and had my phone on airplane mode for over 24 hours and did not experience any drain. There must be some kind of pattern between all the users here. Yesterday we had a user tell us it may be due to VPN being enabled. If we can all think of what the pattern is asides from just turning on airplane mode that will be helpful to the developers. The logs in this case don't seem to helpful.
I definitely didn't have my VPN enabled, but I have 3 quick settings tiles if that helps.
For those who are still experiencing the issue please double check the points listed in this troubleshooting step:
https://companion.home-assistant.io/docs/troubleshooting/faqs#android-app-battery-drain
if you haven't already try the start fresh steps mentioned previously too after checking the points above.
I have followed the "start fresh" steps above, and it does help somehwhat. Now, if I disable wireguard VPN, it works putting the phone in flightmode during the night. The times I forget to disable the vpn, my phone will become A LOT warmer, and experience massive batterydrain.
Well that makes sense. If you have VPN enabled the phone probably thinks it has an active connection to use and so it tries to use it. We can't really fake and work around that because simply checking Airplane mode isnt enough as one can have airplane mode enabled and still use Wifi as an active network. Also we cant check if there is internet available as you can have a local connection to the server without data.
We have seen in another issue where a server that is not down but unreachable also causes weird drain probably because the connections are hanging and timing out instead of immediately failing. Seems to be similar symptoms.
In this case I think you can probably have tasker close the VPN connection when airplane mode is turned on? Kinda odd that hte VPN decides to stay connected even though it has no active connection to use. You woudl think turning on ariplane mode there would indicate to shut things down.