Phone companion app still broken after years of raising awareness - sensors do not update as expected

There is a problem with the companion menu option inside of the home assistant app for phones period. I have been reading the forums and many, many people have raised this issue of sensors not updating over the past year however it still remains. Since this is a community driven project, this post is more for the end users pulling their hair out as to why their sensors on their phone do not update, sometimes update, update when they feel like it, etc.

My setup:

-I run home assistant on a vmware virtual machine (stupid high resources) It runs rock solid, amazing production in general.

  • Nothing with home assistant is exposed outside of my network and it runs on http not https

-I have 3 phones that all run the home assistant app:
Crapple 6s
Samsung S7
Pixel 7 (running Graphene OS)

All phones have the same(ish) issue, simply put the sensors do not automatically update on their own, they must be triggered. Now HOW they are triggered is a little different
Crapple: You must start the app AND it must be in the foreground. This is the most important part, if you leave the app running in the background, nothing updates; however, leaving the app running in the foreground and everything works as expected and boy do I mean instant updates…very very instant fast updates on ALL sensors.

The two android phones are exactly the same issue. Let me be clear here before people jump into permissions, battery restrictions, etc etc. This is not the issues on either phone. Also for those who have not tried GrapheneOS you have even deeper control of permissions (it’s amazing) however both phones having full wide open permissions, no background restrictions, sensor update frequency = “fast always” etc etc they act exactly the same. Sensors do not update on their own. This is where is gets weird. If the app is started and running in the foreground, with some sensors, say the “is the phone charging” sensor, well it acts as expected, instantly letting you know when I pull the cable or put it back in. This sensor also works with the app in the background - but wait…it even updates when the app is not running at all! Again, same symptoms for both android phones. Now, let’s talk about other sensors like wifi. I really want certain automations to happen based on if my phone is connected to the house wifi or not. Looking in the companion app, under “Network Sensors”, all are “instant updates” with the exception of “public ip address” Here is the thing, not a damn one of them update in any way unless you 1) have the app running 2) it’s running in the foreground 3) you go into the companion menu 4) you actually CLICK ON any sensor once.

BUT WAIT!!! there is more!!!

If you ONLY click on the companion menu, two sensors update in home assistant, “wifi link speed” and “wifi signal strength” no others even though you can clearly see in the phone app ALL the other wifi sensors values!! So…on the phone, let’s now click on “wifi frequency” which on the phone says 2462 Mhz and home assistant says “unknown” Gues what…BOOM the home assistant now shows the frequency. Ok on to “Network type” phone says “wifi” home assistant says “unknown” right now…clicking on the sensor now and…BOOM home assistant, logbook, etc now show the network type as wifi.

Serious serious bugs and problems - serious. Again, this is more of a stop pulling your hair out notice, and more of a “this is just broke, deal with it for now” message.

This is most likely to do with permissions on the phones - manufacturers place a very high premium on battery life and Android apps get killed in different ways for different models. Samsung are notorious for this. Have you looked at the troubleshooting section of the docs?

I hear you, but i am here for reasons part, not solution.

Android has very different behavior depending on phone model and kernel, so it is almost impossible to test application for all different brands and models. To overcome this, big software companies build physical and/or virtual device farms and you can test the experience on different devices. I am sure we are not there in home assistant budget, so it would be very difficult to test all these on different devices and more probably debug them.

So, sadly, it is broke.

(PS: I own Xiaomi Poco X3 pro, not facing any of the issues)

As I mentioned in my post, I was hoping no one would say it’s a permission issue - it’s not. Again, running two android phones, one stock samsung (older os) and one brand new pixel 7 running graphene os. Both have the same symptoms and results. It’s a coding issue on the HA companion side to account for all the variations in android versions, etc. Again this is a message to users saying it’s most likely not them. Think about it, if you are using HA in the first place, you are not a novice and you have a great deal of knowledge already. Please stop with a knee jerk reaction of “try the troubleshooting section” or “it’s just you” In this community, with the level of intelligence required, it’s highly unlikely it’s the person.

Well said, wish I could say the same. Not super surprised with Android, however VERY surprised this happens on my wife’s Apple 6.

Feel better now? :wink:

Er… :thinking:

4 Likes

If all the phones have the same issue, yes it may be the app (because there is of course an android app and an ios app, maybe same code base but they are compiled differently) but it may also be the way they are connecting to your network as well. Do you run the home assistant app on them when you are not home and the results are the same, or - ?

Here is a quote from my original post " Nothing with home assistant is exposed outside of my network and it runs on http not https" My phones have no ability to talk with Home Assistant when I turn wifi off and vice vs.

This is from the OwnTracks website:

Certain vendors have their own restrictions for apps running in the background. On these devices, Owntracks might be killed even though it behaves according to the official Android background execution limits.
A list of vendors known to interfere with background apps and a number of workarounds can be found at Don’t kill my app!.

If you’ve checked all that, the next step would be to raise an issue on Github:

Again a quote from my original post

This is where is gets weird. If the app is started and running in the foreground, with some sensors, say the “is the phone charging” sensor, well it acts as expected, instantly letting you know when I pull the cable or put it back in. This sensor also works with the app in the background

I apologize if I did not make it clear in my original post. With the app running in the background (and no it does not magically kill itself if I leave it alone for hours) Some sensors that say instant updates work like they should, some do not.

It’s not me and permissions, it’s not me and settings…it’s how the companion app is coded and how it interacts with specific sensors. I put a great deal of time, thought, troubleshooting and details into my topic before posting.

Whats the problem with the menu option itself?

Does this mean HA itself is not accessible outside your network?

Lets stick to android and not iOS. What exactly is not working? Did you get logs to see if there was an error?

for android this is not true. The app only needs to be started once and again if the app crashed. Otherwise the sensor worker will reconnect after user has unlocked the device post boot or even after the app was updated in the play store.

Actually its very important to talk about permissions and battery restrictions because those are the heart of android. Given you are on a custom ROM you probably have even more settings to consider than a stock ROM.

we are still missing logs and detaisl as to what exactly is not working.

I guess you do not understand how intents and work manager on android actually work because what you are describing is expected.

This must be device specific. On a Pixel device it works as described.

Again more device specific issues. Try a stock ROM to rule custom ROM out. It has been seen in the past that custom ROMs do not always respect android documentation.

please pin point exactly where in teh code the coding issue you describe is

Given that you decided to run a custom ROM you should be willing and able to troubleshoot any issue asked of you and you shoud be aware that they are not by any means perfectly bug free.

There you have it, you shoudl not expect ANY sensors to update if the device cannot communicate to your house.

If you checked the companion app logs you will see errors as such too.

2 Likes

To save yourself time did you report an issue within github?

I know it is tedious but can you come up a specific list of the sensors that do not update (this will allow you to ensure the sensors that update and those that do not is consistent). Then you could also enrich that data with information about which integration, what kind of sensor, etc. This way you may be able to glean more granular pattern of symptom/s to get to the root of the problem.

Also does anyone know if there is a way to put very verbose logging on both the phone app and the host server that is specific to communication between the app and the HA ‘server’? It could be that some informaiton is being sent by the server - or not when it should be - or some indirectly tries to touch the internet for some reason -

Pick one specific sensor that consistently has this issue and try to trace all the communication between it and a phone?

It seems like your issue may be one thing in your network hadware/software communication. Maybe also try different network encryption protocols between your router and one of the phones to see if that makes a difference? (E.G., I did have an annoying hard to resolve hardware/networking connectivity issue which might be the same kind of thing with your situation. I had all manner of nightmare connectivity issues with a nest learning thermostat and changed the location of electronic devices near it as well as replacing the thermostat itself it and finally determined that either my router or the nest thermostat did not properly handle one of the more secure networking protocols - once I changed that all of those issues went away - )

How sophisticated is your network? Do you have anything out of the ordinary set up in your router settings like CIDR, Subnetting, IP6, LLDP, SNMP etc. (I am at the edge of my networking knowledge here)?

Do you know anyone that lives nearby that would allow you to temporarily connect to their HA instance with the app on your phone when on their network, just to see if the sensors work properly then on the phone? If it does work that would prove it was not the phone itself (although maybe still an issue with the app) -

Another possibility is to allow one of the sensors access to the internet and then if you see the problem go away with that sensor being displayed on your phone then you have proven there is an issue with the app related to security in that manner…

1 Like

the in app log viewer will pull all logs we print.

for the HA core side, you want to enable debug logging for mobile_app integration

then you will see ALL communication sent from device to server and vice versa

@dshokouhi I think you hit the nail on the head - @HA_too_much_coding have you looked into both below?

You posted quite a long rant - but if this is all you want, why not use a router based device tracker and be done with it? That will be the first to know if a phone connected to wifi, no companion app needed at all. I know the companion app has a huge list of sensors. But I cannot for the life of me figure what their use case is for 95% of them, other than pure data hunger.

2 Likes

we get requests often for sensors that have somewhat static data or just a setting from the app, those exist because we allow them to be controlled remotely and you need to read the state to do it properly. First time Kotlin learners also like to add sensors as a way to dip their feet in the code. Some of them I do agree as they are more for troubleshooting purposes but a good chunk of them have good purpose. Take the App Importance sensor for example, a good way to know if the app is actively open or not.

Or… ping the phones from HA.

Ah, coding fun! That I understand :smile: To be honest, I enabled all and I have no use for them. I know, I’m an addict. I was trying to make a point and the only use case mentioned is run an automation when someone comes home.

But to get back to the topic, maybe something is wrong, maybe not. The situation described is not exactly run of the mill.

But I do think relying on an app on the device to check if the device is home or not is conceptually flawed in this situation, because the phones are connected on local wifi only. The minute the phone goes of wifi the companion app has no way to notify to HA , so HA needs to assume the device is gone based on long time no updates or unable to reach the phone from HA. A simple ping sensor does just that - check if it can reach the phone. Also, the sensors on the phone are only trustworthy if the phone is home and connected to wifi, so you cannot rely on them for automations simply because they could be stale anyway.

This is a very complicated issue, with several devices and many sensors. The best way forward might be to pick one issue - one phone, one sensor, one problem - and report that on Github. The “raise an issue” form is quite good: requires an exact description and gives an opportunity to add logs. Then take it from there.

2 Likes

I leave them all enabled to ensure battery drain isn’t horrible :slight_smile:

This is only true if your instance is not remotely accessible. If it is then you can count on sensor updates to always come in when the app can phone home. If your instance is not remotely accessible then a lot of the desired functionality will not work as one would expect. In fact a user could be confused because notifications naturally come from Firebase so as long as your server has internet your phone can still receive the notification. A user could perceive that as all of the app should work but that is not the case when you see the logs :slight_smile:

1 Like