Bummer. Hopefully it can be fixed soon. It seems odd that my lovelace config has had cameras on it for a long time yet this is the first I’ve had massive data consumption. Has this HA bug only recently popped up?
Honestly I am not sure, I have yet to be able to reproduce it and neither has the other developers including the frontend team. One of the users in that bug mentioned the data usage got better in a recent HA version so not sure if updating HA will make the situation better for you.
I’m on HA 0.117.2 at the moment, will try 0.117.5 now.
While you’re at it, a new version for the apphas been released as well 
For whatever reason I’m not yet seeing the new version in the Play Store
It has been released yesterday I think, may take some time until it’s available in the app store.
See the blog post here.
Yeah, I had read through that earlier. Just waiting for it to become available for me
Have this been fixed?
My cellular data in november and december is already drained.
See screenshot of the usage 
:
Not sure, after the HA app chewed up 10Gigs in one day I chose to block it from using data unless the app is open in the foreground. Unfortunately that means my doorbell images don’t come through, just the text part.
I haven’t been game to test it out since… especially since @dshokouhi’s response above suggests that the issue won’t be sorted until a HA side issue is resolved.
Happened to me as well today with live cameras. 4GB… Can this be fixed?
I have the same problem also. Happy to assist with debugging if needed.
Does anyone know if this is an issue with any of the other HA apps/frontends for Android?
to my understanding the issue also exists in Chrome for android…just remove your live view picture entity cards and you will be good.
Nothing the app can do until its fixed in the front end. If you guys really need live view picture entity cards take them off the home page and put them in another tab or dashboard. There are quick and easy workarounds for this so you guys don’t eat up data.
this happened to my father’s phone today with the companion app.
9 GB used in one day.
He never opens the app. its used for location tracking only.
“auto close connection” has been on for months with no issue until today.
I do have some live view cameras on a lovelace page, but no issue until today on 1 phone, not all.
I think this extends beyond just cameras (I don’t have cameras). I created a basic template widget on Android along with about 12 toggles and I watched the app use almost a gig of data in 4 hours.
Alarm:
<font color="{% if is_state('alarm_control_panel.tampa_alarm','disarmed') %}green{% else %}red{% endif %}">
{{ states('alarm_control_panel.tampa_alarm')|title }}</font>
<br/>
Garage:
<font color="{% if is_state('cover.palmira_garage_2','open') %}red{% else %}green{% endif %}">
{{ states('cover.palmira_garage_2')|title }}</font>
<br/>
FrontDoor:
<font color="{% if is_state('lock.front_door','locked') %}green{% else %}red{% endif %}">
{{ states('lock.front_door')|title }}</font>
<br/>
BackDoor:
<font color="{% if is_state('lock.back_door','locked') %}green{% else %}red{% endif %}">
{{ states('lock.back_door')|title }}</font>
It seems like each refresh of that data uses like 7 megs of data. I temporarily disabled background but I believe on Android widgets continue to use data even with that setting disabled. With that setting disabled I still watched data increase for that app. Once I removed that widget (only about 12 toggles remain) data seems to be under control.
Few questions.
- What could possibly be using 7Megs of data for each service call on that widget? I can’t imagine that json is that large. My guess is it’s refreshing all state data each time that widget refreshed.
- Can anything be done (should I open a issue on git?) To make those widget calls less impactful?
I realize there are Android limitations for widgets using background data but the amount of data in each call seems excessive.
For now I’ve deleted that template widget and am keeping background data off.
widgets only send a HTTP post and do not account for 7megs thats for sure…your data is probably coming from the frontend being loaded and other images refreshing like media players etc…
use chrome remote debugging to look at the network calls from the HA frontend
https://developer.chrome.com/docs/devtools/remote-debugging/webviews/
Template widgets in particular is a single call to HA: https://developers.home-assistant.io/docs/api/native-app-integration/sending-data#render-templates
I’ll do that. But the fact that with everything exactly the same (keep app in background. Don’t open it. Background data off for app. All 12 widgets) if I add that widget to my desktop, it starts consuming and continues over the period of time. If I simply remove that widget it goes under control. The rest of the components in my dashboard shouldn’t come into play unless implicitly it’s refreshing that dashboard for each template widget call.
What happens if you use a template widget using the default text? Look at the logcat logs to prove your point if you think its making excessive calls as we will see that there. I have plenty of template widgets and none of them cause excessive data usage.
This is what I am seeing. I use a caddy reverse proxy and can see all the requests coming on. I ran this to grab my log data for this IP only of this android device while I clicked refresh on the ‘default template widget’ with the text “Enter Template Here”.
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973193.72407|<IP>|NULL:|Mozilla/5.0 |3.291252223|0
POST|200|<redacted>/api/webhook/<redact>|<IP>|NULL:|okhttp/4.9.0|null|null
POST|200|<redacted>/api/webhook/<redact>|<IP>|NULL:|okhttp/4.9.0|0.620719388|35
GET|200|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973203.599966|<IP>|NULL:|Mozilla/5.0 |null|null
GET|200|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973203.599966|<IP>|NULL:|Mozilla/5.0 |3.080549226|37552
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973206.996367|<IP>|NULL:|Mozilla/5.0 |null|null
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973206.996367|<IP>|NULL:|Mozilla/5.0 |3.096843984|0
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973213.56957|<IP>|NULL:|Mozilla/5.0 |null|null
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973213.56957|<IP>|NULL:|Mozilla/5.0 |3.270496221|0
GET|500|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973213.507984|<IP>|NULL:|Mozilla/5.0 |null|null
GET|500|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973213.507984|<IP>|NULL:|Mozilla/5.0 |3.356048396|0
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973223.557617|<IP>|NULL:|Mozilla/5.0 |null|null
GET|500|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973223.557617|<IP>|NULL:|Mozilla/5.0 |3.221655619|0
GET|200|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973223.654615|<IP>|NULL:|Mozilla/5.0 |null|null
GET|200|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973223.654615|<IP>|NULL:|Mozilla/5.0 |3.264383023|37552
POST|200|<redacted>/api/webhook/<redact>|<IP>|NULL:|okhttp/4.9.0|null|null
POST|200|<redacted>/api/webhook/<redact>|<IP>|NULL:|okhttp/4.9.0|0.061085367|35
GET|200|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973223.557617|<IP>|NULL:|Mozilla/5.0 |null|null
GET|200|<redacted>/api/media_player_proxy/media_player.living_room_shield?token=<REDACT>&cache=1616973223.557617|<IP>|NULL:|Mozilla/5.0 |6.676288868|3210247
GET|200|<redacted>/api/media_player_proxy/media_player.loft_shield?token=<REDACT>&cache=1616973233.621011|
Its interesting that each template refresh is somehow triggering a refresh of those media devices as well. The paste above is consistent for each refresh. (Its also interesting that I’m getting HTTP-500 errors but that is a different issue that I guess I need to track down but is likely increasing the data consumption in general).
Would it be expected for the media devices to be refreshing on template refreshes when those templates have nothing to do with media? I’ve not opened the app or anything else. I’m simply clicking the widget to refresh the default widget.
EDIT: BTW. If I remove the media players from my lovelace dashboard and perform the same procedure, I dont see the entries on the logs
do you have media player widgets as well?
the template widget only makes one call to HA so if your seeing anything else its not from the HA app https://github.com/home-assistant/android/blob/42ed8928dd1fb3e41566d6a3d25214e5f382e8ca/app/src/main/java/io/homeassistant/companion/android/widgets/template/TemplateWidget.kt#L127
one thing we do is update all widgets at the same time when we can just to make things easier but it wont be 7mb of data as its only text.
in HA if you enable debug logging for mobile app you will see all the calls being made homeassistant.components.mobile_app: debug too
1 Like
No. The only widgets I have are toggles for garage doors and locks. They call basic scripts or scenes nothing which uses a media player. I only added those yesterday and haven’t done much with the players.
I’ll look a little more tomorrow but it is very consistent that a widget refresh was triggering those media player entries until I removed them from lovelace. Remember too that background data for that app is completely disabled. While the widget may only be making an explicit post, it does go through the app to do it and when it does, it seems to be making those other implict calls as well.