SensorWorkerBase set foreground type based on WebSocketManager status

[TimoPtr]

Summary

This PR is a PoC to try to address an issue for users using Persistent Connection #5939
My though on this issue is that the SensorWorker might get the WebSocketManager to be killed by the system when the overall limit of 6h is reach from the sum of running time of these two worker, even if the WebSocketManager is using remoteMessaging. This PR is an attempt to change the type of SensorWorker so that when it starts when the Connection is persistent it won't start as a dataSync but as the same type as the WebSocketManager.

This is definitely a hack, so we need to first test if this assumption is valid.

[jpelgrom]

In addition to testing your assumption, this may or may not be a Play Store policy violation if Google wants to be even more annoying than they currently are: https://support.google.com/googleplay/android-developer/answer/16559646?sjid=6427937707813206044-EU&visit_id=638978871294180277-1134189417&rd=2#fgs (we need to upload video/description of our usages)

Sensor updates can run as a background service / pure WorkManager job in theory, but are throttled on some devices when doing this making sensor updates less reliable.

[Soukyuu]

In addition to testing your assumption, this may or may not be a Play Store policy violation if Google wants to be even more annoying than they currently are: https://support.google.com/googleplay/android-developer/answer/16559646?sjid=6427937707813206044-EU&visit_id=638978871294180277-1134189417&rd=2#fgs (we need to upload video/description of our usages)

Sensor updates can run as a background service / pure WorkManager job in theory, but are throttled on some devices when doing this making sensor updates less reliable.

Should it be a violation for the google play version, but work otherwise, please consider ifdefing it for the FOSS/minimal version only.

[TimoPtr]

In addition to testing your assumption, this may or may not be a Play Store policy violation if Google wants to be even more annoying than they currently are: https://support.google.com/googleplay/android-developer/answer/16559646?sjid=6427937707813206044-EU&visit_id=638978871294180277-1134189417&rd=2#fgs (we need to upload video/description of our usages)
Sensor updates can run as a background service / pure WorkManager job in theory, but are throttled on some devices when doing this making sensor updates less reliable.

Should it be a violation for the google play version, but work otherwise, please consider ifdefing it for the FOSS/minimal version only.

That's a possibility but before we want to validate the assumption, so if you are able to reproduce the issue please try to disable all the sensors and see if the issue persist, then test the APK from this branch.

[Soukyuu]

Yes, forgot to mention that in the ticket, I've disabled the sensors in the app (was only battery anyway) and will now see if the persistent connection breaks down again.

[TimoPtr]

Yes, forgot to mention that in the ticket, I've disabled the sensors in the app (was only battery anyway) and will now see if the persistent connection breaks down again.

I've made a new version more aggressive if you can test again 🙏🏻

[Soukyuu]

Did I get the correct artifact? Went to the "checks" tab on this page -> pull request, then bottom of the page to get to the artifact. Installed minimal version but it reads:

Expected to see a hash of one of the pr commits in there.

[TimoPtr]

Did I get the correct artifact? Went to the "checks" tab on this page -> pull request, then bottom of the page to get to the artifact. Installed minimal version but it reads:

Expected to see a hash of one of the pr commits in there.

That's the right one 👍🏻

[TimoPtr]

Did I get the correct artifact? Went to the "checks" tab on this page -> pull request, then bottom of the page to get to the artifact. Installed minimal version but it reads:

Expected to see a hash of one of the pr commits in there.

Did you see any changes during this 20 hours?

[Soukyuu]

Well the connection was working for around 20 hours, but still failed at some point. I force-closed the app without looking at the logs assuming the don't reset after restart, so that was my mistake. I'll look at them once it fails again.

[Soukyuu]

New day, same behavior. I'm not seeing anything failing and the notification is still there. Calling notify fails with the usual not connected to local push. I'm switching to airplane mode overnight, so maybe staying offline "too long" breaks stuff?

homeassistant_companion_log_10-14-2025_9-45-57.txt

[TimoPtr]

New day, same behavior. I'm not seeing anything failing and the notification is still there. Calling notify fails with the usual not connected to local push. I'm switching to airplane mode overnight, so maybe staying offline "too long" breaks stuff?

homeassistant_companion_log_10-14-2025_9-45-57.txt

So it's better than before no? It seems that the services are not killed anymore.

The notify issue might be something else. I see from the logs that everything seems to be connected fine. It takes some time for HA to recover from airplane mode.

[Soukyuu]

I'm not entirely sure. For me the connection usually held longer than for the ticket author. I have now created an automation to test the notification at hourly intervals, will get back to you with the results.

Not sure I understand the airplane recovery part, I'd expect it to recover instantly as when I force close the app. I have also tried switching airplane mode on and off briefly and the notification worker reconnected after about 10 seconds (which is fine), but the issue with airplane mode overnight is permament.

I also saw that everything seems to be connected at least from the view of the companion app, maybe the issue is also partially on the server side?

[TimoPtr]

I'm not entirely sure. For me the connection usually held longer than for the ticket author. I have now created an automation to test the notification at hourly intervals, will get back to you with the results.

Not sure I understand the airplane recovery part, I'd expect it to recover instantly as when I force close the app. I have also tried switching airplane mode on and off briefly and the notification worker reconnected after about 10 seconds (which is fine), but the issue with airplane mode overnight is permament.

I also saw that everything seems to be connected at least from the view of the companion app, maybe the issue is also partially on the server side?

I forgot to ask on which version of Android are you?

[Soukyuu]

16, running latest grapheneOS without google services.

[Soukyuu]

My hourly notifications had some troubles at 2pm, server claims it was sent successfully, but it did not show in the app notification history. I've then sent a notification manually at around 2:08 and it was delivered correctly, so some sort of recovery did take place - but nothing visible in the logs.

Around 4:30pm I left the house and the 5pm notification did not arrive - the connection was broken and has not recovered so far, even though I returned home. This time, there is something in the logs though, let's hope that might give you an idea:

Home Assistant log 7d53deee9ac1.txt