It is very annoying that the sensors of a non-phone cannot be updated when the mobile application is not loaded. There is no way in the mobile app to make it a mandatory service to download in the background. As soon as the application is unloaded, the update of the mobile phone sensors stops sending data. This is very inconvenient because you constantly have to monitor the status of the home-assistant mobile application for timely and up-to-date updates of the phone’s sensors.

I don’t monitor my app and it works just fine.
You need to make sure the app has rights to run in the background.

if I unload my mobile app, the sensor update stops functioning. Therefore, I propose to make sending data from mobile phone sensors separate from the graphical interface of the application. I also propose to introduce a function that will be able to send data regardless of whether wi-fi or mobile Internet is enabled. According to the following algorithm, for example: If wi-fi or mobile Internet is disabled by the user. enable these methods of sending data from mobile phone sensors and return them to the state in which they were originally.
In order to have guaranteed information about the status of the phone’s sensors. Regardless of the user’s actions and the phone’s power saving modes.

How do you unload it?
Do you force stop the app in settings → apps, or do you swipe away open apps in the “quick access menu”?

It already does. Unless you force stop the app as described above.

How is the app supposed to send data when wifi and mobile internet is disabled?

+1 and same for the other issue ! If you unload the app you can’t expect sensors to update: it’s just logical ! Just stop unloading the app and it’ll update all time :slight_smile:

Just to be sure to understand properly: when you say unload app you mean kill/end the app or just app in foreground ?

If I clear the application from RAM. Sending data from sensors stops. Therefore, I suggest that the information transmitted from the sensors be transferred to a separate service that will not depend on the downloaded mobile application, as well as the power saving mode, which, if incorrectly configured, respectively close the application, which accordingly leads to the termination of the transmission of information from the sensors of the mobile phone.

I think it’s an android restriction you can’t go around ! If it runs a background service it has to get a notification displayed at least

for that it’s up at user to setup properly the power saving mode to prevent app being unable to transmit data (you can also force the app to keep connection with HA permanent but it might impair battery life depending of phones !

I don’t know what you mean by RAM.
But lets go back to the days of buttons. A few years ago Androids had three buttons, Home, back and the square.
The square opened a menu where you could quick access the open apps.

If I open that menu and close HA, then I still get updates from my phone to my HA install.
Only if I open settings - Apps → HA → force close does it stop.

If you configure your app/phone the way you want it to behave then it will behave that way.
That includes power saving.

That’s why I suggest putting these sensors in a separate service, separate from the graphical application that would allow you to set the frequency of sending from these services. after all, there are system services in Android that are never unloaded regardless of the power saving mode.

And that is why we suggest you just configure your phone to your liking and there is no need to change anything else that could cause breaking changes for the rest of us.

Also, I would be surprised if non-system apps had the ability to create system level services in the first place. So that would likely be impossible.

  1. The app background worker needs to remain scheduled, killing the app or removing from recents can indeed stop this from happening.
  2. The app will restart the worker upon device reboot as long as the schedule remained intact.

this request cannot be fulfilled as its part of the android platform behavior.