Thanks for the reply!
I’m still on 11.5 as I’m not fan of new configuration panel, but will surely upgrade and try.
Thanks!
Hello again,
Everything is up to date now (RasPi, HA core and HA app), and it still doesn’t work properly.
When tablet is not connected to power, then it “seems” to be working OK (I cannot fully confirm because it was only OK yesterday for several hours), however, apparently when the battery is fully charged and still connected then it starts to misbehave. 
I’ve attached latest log, it shows some different entries at 11:21 when it broke.
Thanks again!
EDIT: Nope, doesn’t work correctly when not charging, same behavior observed today.
:(((((((((
no logs are attached here
Goddammit. Sorry.
(Is there another way to attach it?)
01-19 11:36:16.233 11335 11365 D UrlRepository: localUrl is: false and usesInternalSsid is: false
01-19 11:36:26.280 11335 11365 E SensorReceiver: Exception while updating sensors.
01-19 11:36:26.280 11335 11365 E SensorReceiver: io.homeassistant.companion.android.common.data.integration.IntegrationException: java.net.SocketTimeoutException: failed to connect to /192.168.0.136 (port 8123) from /192.168.0.99 (port 57140) after 10000ms
01-19 11:36:26.280 11335 11365 E SensorReceiver: at io.homeassistant.companion.android.common.data.integration.impl.IntegrationRepositoryImpl.updateSensors(IntegrationRepositoryImpl.kt:580)
looks like HA has a hard time connecting to your server and the connection times out.
01-19 11:21:13.951 11335 11335 I zygote64: Rejecting re-init on previously-failed class java.lang.Class<androidx.webkit.internal.WebViewRenderProcessClientFrameworkAdapter>: java.lang.NoClassDefFoundError: Failed resolution of: Landroid/webkit/WebViewRenderProcessClient;
01-19 11:21:13.951 11335 11335 I zygote64: at android.content.pm.PackageInfo androidx.webkit.WebViewCompat.getCurrentWebViewPackage(android.content.Context) (WebViewCompat.java:353)
This looks more like a device issue with webview as its unable to get any data on it. Seems like a bad implementation from the manufacturer. The call it fails on is one added in API 26
and we do indeed only use it when the device supports it
Despite the numerous log lines above it is still able to get it.
01-19 11:21:13.953 11335 11335 D WebviewActivity: Current webview package com.android.chrome and version 97.0.4692.87
It looks like chrome is used by default here, I dont suppose you ahve android system webview installed as a system app right? some devices use chrome while others use webview
looks like HA has a hard time connecting to your server and the connection times out.
What would that mean, wifi issues on tablet or on RasPi? Or both?
The call it fails on is one added in API 26
This really doesn’t mean much to me, but from the link attached Android 8.0 has the API level 26
It looks like chrome is used by default here, I dont suppose you ahve android system webview installed as a system app right? some devices use chrome while others use webview
Again, just a n00b here, but both Chrome and Android System WebView are installed (and up to date) on tablet. Not really sure what WebView is/does as I can’t open it (like some other app). Chrome is set as default browser, if that means anything.
What I can see is that this is waaaaay beyond me. I thought it would be a simple plug&play action with the tablet, turns out not to be. I have a lot more information now, but am not any more knowledgeable.
If the budget allows I might try getting a newer Android tablet (10/11) and see if that one does any better.
Thanks for your support.
Well, new and interesting development. Today I tried to leave HA open on my PC… and after several hours I got the same problem! So apparently issue is not on tablet side, but on RasPi side. Will try to connect RasPi via cable instead of wifi.
Thanks for your time and effort, it is really appreciated!
Just to share final thoughts and close the problem… Apparently, the problem was on the RasPi side (connection issues). Several days now since it’s on cable and not wifi, and everything works perfectly! So I cannot confirm nor deny whether HA updates on tablet and RasPi were even necessary.
Thanks to @dshokouhi for your assistance and for pointing me in the right direction!
1 Like
Saw your post and even though it is unrelated, just want to chime in and say that screen always on with a charger that is always on will most likely affect your tablet negatively. I use sort of the same setup as you but have put a smart plug that starts charging the unit below 30% and stops above 80%.
Happy to hear that you have solved the problem 
What do you mean “affect your tablet negatively”? Like shorten it’s lifespan?
I’m not that worried, it’s an “older tablet” that isn’t utilized in any other way, so I did this to make it useful. 
Although the idea of connecting it to a smart switch doesn’t sound bad!
Anyhow, I didn’t want to nag again, but the problem still persists. 
Twas working perfectly for several days, then started misbehaving again. Usually force stop of HA app followed by clear cache and then tablet restart helps for that day. I still have no idea what is the root cause, but makes no sense to buy a newer tablet to test since I have no other use for a tablet anyway. sigh
Ah yes, from some other forum posts I got the impression that it would wear out faster. Could it be a setting in the user profile of the app? This thread: Homeassistant App for Android "Connection lost", not reconnecting - #3 by simatao has a solution with a checkbox that automatically kills connections, noticed that mine has it set to on as default
Hi,
Thanks for still sticking around.
I’ve actually come across mentioned post, and tried it myself, however it doesn’t seem to have much effect in my case. It works and breaks (randomly?) disregarding the state of the switch (some days it breaks if the switch is off, other is works with on and vice versa). That being said, usually I leave it at off.
You seem to have tested most things so these questions might be a bit redundant, but asking so I understand correctly.
The freezing and lagging, it is just that the values aren’t updating right? Since you can switch to another lovelace card I assume that the app is still responsive.
With RasPi on cable instead of wifi, do you still get the same problem on PC?
Since you have tried almost everything with the tablet, it could be that the RasPi is the problem. I am thinking in terms of like how old the model is, if there is a lot of space left on SD-card, quality of SD-card (I used to use cheap ones, switching to a better one has improved the system beyond words) and such.
I have also found that if the machine is already working hard, things like HA database size, using recorder to store every state very often, and using loads of things in the same UI can make it slower. Anything you can notice that might be off in terms of these things?
You seem to have tested most things so these questions might be a bit redundant, but asking so I understand correctly.
Please do ask, as I’m quite inexperienced with both RasPi and HA, all that I do seems to be same couple of things over and over again maybe in a different order, but somehow the results seem to differ every once in a while. That’s the most confusing thing, same actions giving different results.
The freezing and lagging, it is just that the values aren’t updating right? Since you can switch to another lovelace card I assume that the app is still responsive.
Exactly. App is still responsive. When I switch to another card something in the background apparently reconnects/refreshes and then all the values start working again, for some period of time. As I’m writing this, today seems to be a good day, it’s still working.
One perhaps interesting thing that I found the other day- when checking the exported log, there were no entries for the minute and couple of minutes prior to then the time on screen stopped (basically when it stopped being responsive).
With RasPi on cable instead of wifi, do you still get the same problem on PC?
Unfortunately haven’t tried that yet.
Since you have tried almost everything with the tablet, it could be that the RasPi is the problem. I am thinking in terms of like how old the model is, if there is a lot of space left on SD-card, quality of SD-card (I used to use cheap ones, switching to a better one has improved the system beyond words) and such. I have also found that if the machine is already working hard, things like HA database size, using recorder to store every state very often, and using loads of things in the same UI can make it slower. Anything you can notice that might be off in terms of these things?
Very interesting aspect, wasn’t aware of this (as said, am pretty new to RasPi world). I have a year old RasPi 4B with 4GB of RAM. Not exactly sure which SD card is in, but am pretty positive that it is uSD HC class 10 32GB that I used in my previous mobile. And just checked, around 15GB are used, so space shouldn’t be an issue.
Recorder is something that I was planning to go over, to check the possibility of disabling some less important signals. Currently I have it set to 1min storing interval and recently changed store time from 7 to 30days (auto purge is on). Current db size is around 170MB but expect it to grow due to store time increase.
However I just run SD card speed test on RasPi (results at bottom) and it might be one of the causes!
Will try to test one of the spare cards I have lying around.
Thanks for the interesting new approach! And sorry for the veeery long post.
Test : SD Card Speed Test
Run 1
prepare-file;0;0;5038;9
seq-write;0;0;7674;14
rand-4k-write;0;0;370;92
rand-4k-read;3142;785;0;0
Sequential write speed 7674 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 92 IOPS (target 500) - FAIL
Random read speed 785 IOPS (target 1500) - FAIL
Run 2
prepare-file;0;0;7073;13
seq-write;0;0;7896;15
rand-4k-write;0;0;312;78
rand-4k-read;4441;1110;0;0
Sequential write speed 7896 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 78 IOPS (target 500) - FAIL
Random read speed 1110 IOPS (target 1500) - FAIL
Run 3
prepare-file;0;0;7021;13
seq-write;0;0;8329;16
rand-4k-write;0;0;332;83
rand-4k-read;5042;1260;0;0
Sequential write speed 8329 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 83 IOPS (target 500) - FAIL
Random read speed 1260 IOPS (target 1500) - FAIL
Test FAIL
EDIT: Corrected recorder storing (commit) interval from 1s to 1min.
EDIT2: Added RasPi model, forgot before.
I was thinking of one of three issues:
- The connection is killed and not re-established or
- The HA system itself is running slow and causes the issue
- Your WIFI (or the tablets WIFI) might be spotty
Based on your answers the specifications of the HA system really shouldn’t be a problem, you seem to have a lof ot disk space and RAM, and the PI is new as well. Db size is also not that big, I think mine is just north of 1GB and it is still running fine.
The speed test of the SD card was interesting, looks like the random-IOPS-tests were far from the expected values, so it might be the problem. Will be really interesting to see if it improves with another (better) SD-card 
Regarding WIFI, I think that since both the tablet and PC showed the same results at some point, it is probably not the tablets WIFI that is the problem. You can always run a WIFI test on the tablet as well to see if there is anything that stands out
I have ordered a new state-of-the-art A2 SDXC card, as they are dirt cheap. Should arrive in a couple of days so will come back with new data.
Also one thing that I came onto recently- overlapping frequencies of wifi and zigbee. In my case it could be an issue since RasPi with it’s usb zigbee dongle is literally a few cm from tablet’s wifi (everything on zigbee network is running fine, so it might somehow “obstruct” tablets wifi connection). Since it’s not simple to change zigbee channel, I’ve changed my wifi channel to the other end of the spectrum. We’ll see behaviour in next couple of days (before the new SD card arrives).
What is most interesting/annoying to me is, even when I don’t touch anything on either system, there are days when HA starts and works normally entire day, and there are days when it immediately breaks (tablet is on auto power on/off with some autostart program to start HA).
1 Like
Ooh, didn’t think about overlapping frequencies, did it make any difference? I have my router ~50 cms from my RasPi which has a ZWave-dongle connected to it. Zigbee also connected into the PI but with a 1 m cable, otherwise I get 0% coverage for Zigbee 
It’s been what, 2-3 days since I’ve “segregated” channels (zigbee low wifi high end of spectrum), so far it works flawlessly. However it also worked good for 5-6 days before and then went to shit, so I’ll give it a couple days more before I call it a win.
For sure connecting RasPi to LAN helped, as before 2 wifi and 1 zigbee devices were fighting for signal in a very confined space. Otherwise haven’t had any issues with my deconz stick, probably helping that apartment is open-space style.
1 Like
So, hopefully a final post in this soap opera. Everything is working fine last 7-8 days, so I’m ready to call this a win. Apparently main problem was overlapping of wifi and zigbee signals (as said, in my case tablet is literally few cm away from Raspi). Since RasPi has been wired instead of wireless and since wifi channels have been put away from zigbee channels, system seems to be running perfectly.
Things might not be what they seem, wasn’t HA or android issue after all. Hopefully this helps someone down the line.
1 Like
Great to hear!
1 Like