Hello,
unfortunately not… 
actually I do not thing that the issue is directly related with fully. I actually think that the issue is the tablet, or better the android system. It seems that it deactivates CPU and/or wifi then the screen is off for some time. I tried a lot with setting wakelocks (via fully and/or with other apps), but nothing helped so far.
I was able to compensate the issue a bit by keeping the screen on (I was using the fully screensaver with lowest brightness - but this still produces some unwanted light, especially at night…)
what tablets are you using and which android version? (I have asus tables running with Android 7)
I suspect the same.
(have a Xido X111 with Android 5.1.1)
That’s a pity - Fully Kiosk is super!
hi,
I did some further testing yesterday,.
Whenever I turn Off the Tablet Screen some minutes later I have the performance issues. That is also in-line with some tests I did early, where I disabled the ScreenOff function in fully and used the screensaver (with lowest brightness) instead. I did not observe any performance issues, but I switched back because lowest brightness is still bright, especially at night, and the power consumption was much higher…
What I did last night; I opened my HABPanel Dashboard in a Chrome Browser on my Tablet, turnd off the screen and waited for a couple of hours. To my surprise today in the morning my HABPanel was still working in Chrome, without any performance issues.
I’m honestly not an Android expert, but it’s currently hard to believe that the issue is really just related to Android and/or any wakelocks within. If the Tablet would turn off CPU and/or Wifi, I would see the same issue using chrome, I assume?!
What I have seen HabPanel actually starts the Webapp once opened and is than somehow connected the the openhab eventbus, at least I can see a lot of item refreshes walking around. This is also happening then I do have the performance issues. In these timeslots I also see a lot of communication between my tablet and the openhab server, so I do not expect that the wifi connection is the issue.
I currently actually think that it has something to do with the javascripts running in the webview implementation which is somehow started by fully? I know this is still a bit strange and most likely technically not 100% correct, but as said, I’m not an Android Expert 
Perhaps someone here is able to help? Or give at least some further ideas what to check?
Thanks Martin,
I think this is very helpful.
(Just to make sure from the beginning: I am not Android Expert either 
I always suspected Android beeing the issue, but your Chrome Test shows obviously tells a different story.
Have you placed this information to Аlexеy (Creator of Fully)?
His response has always have been quick and helpful.
I am also reading the Battery state using Fully.
Having said this I checked the battery settings in android (never did this before) and recognized that Power savng mode was ON - is this the case on your tablet as well? (Just checking if this might have solved my issue!?)
I will keep you posted.
Have you tried HPV already as Andrew pointed out above in this thread:
Or is there still any advantage of using FKB?
[quote=“NCO, post:18, topic:83492, full:true”]y.
Having said this I checked the battery settings in android (never did this before) and recognized that Power savng mode was ON - is this the case on your tablet as well? (Just checking if this might have solved my issue!?)
[/quote]
getting rid of the power safe mode was one of my first steps 
also enableing all kind of Priority Modes, wakelocks etc. unfortunately nothing worked until yet,… 
you disabled power safe mode now, I assume? let me know if it helped pls.
I tried it several times, but was always stuck with some point. mainly around TTS, where I was never able to get any word ouf of my tablet. most of my smarthome use-cases make heavy usage of TTS, and since until now no local voice synthesizer satisfied me I still relay on google,…
but perhaps I’ll give it a try again.
I don’t remember the (dis-)advantages of either FKB or HPV, but I do remember, that for my use case FKB was the better choice after trying both.
It’s quite a while ago, so another try might make sense.
hello,
yesterday morning I had another idea. I now have Habpanel Viewer running as a App managed by Fully. So I still have Fully to make motion detection, Battery stats, etc. but I do have Habpanel Viewer which seems to be better in keeping performance.
I startet this test on two of my tablets. Both seem to be faster and more responsive, however do behave a bit different… Perhaps someone else has time to start such a test to get some more experiences?
thanks
martin
hello,
brief update, i ran around 3 or even 4 days now with HabpanelViewer started as an App out of Fully Kiosk Browser. I haven’t seen my performance issues till now. Even if the Screen is off for hours, Habpanel Performance is OK after screen turned ON again.
It seems that HabpanelViewer Browser implementation is a bit slower for Habpanel than it is in Chrome/FullyBrowser, but it’s useable and OK.
Today I migrated my last tablet in this scenario and hopefully I can soon close this issue
for the sake of completness, i also tried this new FullyAppKiosk App. Idea of the App is good, it holds one App and puts a Kiosk around. Snce it offers nearly the same API as FullyKioskBrowser it was more or less integrated into my system after install. As App i started HabPanelViewer. Was working but since I had issues with TTS i moved back to above mentioned (Fully Kiosk Browser with running HabPanelViewer as an App)
And one more, during my investigations I found a thing called Chuwi HI 10 Air. A Windows based Tablet, like a Surface, but much cheaper. I played around a bit with it, installed some linux and perhaps this could also be the next gen of my Smarthome Displays. If i find some time I’ll write a separate article about it.
cheers
martin
1 Like
Now I remember the (for me important) difference:
Locking the screen!
When I am away, I can lock the fully screen and there is no option to control OH unless I know the pin code of Fully.
When locking the screen on HPV, it only becomes dark, but can be revived with the power button and is operational. That’s unfortunate if someone breaks into my house.
I am currently running HPV and am very happy with the performance.
What I did was:
- Disable power safe mode in Android battery settings (as mentioned above)
- Installed Habpanel + habpanel-filter (for 2.5 stable) from here:
[SOLVED] HABPanel sluggish - #28 by arctus
However, because I like the functions of Fully better, I will switch over again to compare the performance on the current settings.
This might take a while.
some for me, I’m still running HPV as an App in Fully. Performance is quite good, and I can make usage of all the Fully Features.
But, there are still two things to investigate…
Firstly, I seems that HPV reacts a bit slower than Fully Browser and Chrome itself. It’s not the same Performance Issue as before, but when I press a button it take some more milliseconds to react. Did you, or someone else, experience the same?
Secondly, Running HPV as an App in Fully seems to be more unstable on my tablets, meaning that either Fully or HPV crashes. Anyone out there which a comment on HPV stability after running a couple of days 24 hours a day?
@martin111, I’m just curious how performance been since you last posted about this issue. Are you still running HPV as an app in FKB?
Hello,
yep, I’m still running HPV as an app in FKB.
From a performance perspective it’s actually quite good, although I feel that HPV is a bit slower than a browser, like chrome, and also as the webview implementation in FKB. But performance is always the same.
however, although performance is ok, I’m not happy yet.
I have to run both apps not in kiosk mode (in any other combination it’s not working) and restarts (on error) are not working properly, meaning sooner or later my FKB crashes and although HPV still runs, the features I require from FKB are not availabe anymore,…
What’s also missing is, that I cannot change the dashboard remotly. I know that I can associate some items to control HPV but afaik this needs to be done on the tablet, which is perhaps ok for the 4 tablets I have right now, but I want to increase this number
so, meanwhile I started to work on some alternatives, but not there yet
I am running a ASUS tablet with Android 6.0 and full HD display.
Habpanelviewer is for me slower than the Fullykiosk browser. So I am using the Fully.
It works good, but I found that running charts drains the performance. I had a chart with displaying 5 items in life update mode. This nearly brings habpanel down to no more response after 1h or so.
Now I reduced to 2 items in the chart and it works ok, maybe 1-2 sec delay. After a reload of the page the performance is back immediately.
I see the same behaviour on a WIN10 PC with chrome browser.
So there is some performance issue with charts in Habpanel.
Compile Chromium yourself after removing features you know you’ll never use. I use this quite efficiently even on an orange pi zero
sounds interesting. I’m running some tests on a raspberry pi zero, working fine there too, once it started I do not observe the issues I face on an android tablet …
Thanks for the update. It feels like what we really need is a way to force Android Webview to seek updates instead of relying on cached data, or perhaps just disable the cache entirely. That’s a little beyond my skill set, though.
I disabled all caches via FKB - not sure it it really disables all caches, but at least form a configuration point of view FKB shouldn’t cache anything.,