Not sure if this is the same issue or not, but I just upgraded to 1.5.2 (build 15115) and am still seeing some wierd behaviour related to this on my android phone (Samsung Galaxy S21).
When first opening the app, it takes approx 30 secs to “fully load”. The way I can tell this is that on my main dashboard it doesn’t show the hub mode or the HSM status (or any other tile status eg. lights) for almost spot on 30 seconds.
And then like clockwork, every 30 seconds afterwards, the screen goes blank like its refreshing/reloading its connection and we go through the cycle again.
I’ve actually been having this issue again. it was really snappy for about a day, now it is even worse than before. I just hadn’t gotten around to bringing up again.
EDIT : Just to offer a disclaimer, I did receive a beta update earlier this evening, and I have not tested it yet to see if the issue still presents itself with this new build.
Folks - I really am sorry this is persisting and not something that is easily fixed. I’m going to reverse all of the recent changes and revert back to the previous way it was polling for device updates.
I had moved to a more efficient method (that is undocumented) and it seems to also be causing some issues (either because I’m doing it wrong, or it is missing features) - so to avoid this becoming a really painful issue, I’ll abandon the change and review how best to move forward as part of a beta.
Thanks - can you also look at testing an Android device, as that’s probably my weakest testing area given I’m more of a Windows/Apple ecosystem man (I do have an Android to test with, but haven’t witnessed any issues).
I haven’t haven’t had a chance to even update windows yet, and never saw it on windows, but I’m on iOS, when I did have an opportunity to try it this morning the lagg was still there.
Fascinating, as that’s the core testing platform for me, and haven’t seen the issue since the fix earlier. So wondering what you’re doing (or I’m not doing) that has caused it to return.
Would you mind swiping up on the app, quitting it, and restarting and letting me know if the experience seems stable (for the time being) or if immediately you have the same long delay before devices report status.
Honestly I haven’t changed much in awhile. It seems to happen most frequently when the app has been closed for a period of time and lags the longest right after opening it initially. For instance, when I first got home, the app had been closed all night, and there was a substantial delay in it opening and updating. I just tried what you suggested, and I did not get the lag this time, but the app also hadn’t been closed for very long. for me the tell is usually that the weather tile is black, the fan icon on the thermostat tile isn’t spinning, and other icons that should be on don’t indicate anything. On a hunch, I just checked background app refresh, and hubivue isn’t even listed there. I have very few app that i allow to refresh in the background.
hubiVue will not refresh in the background. When no longer active, it essentially shutsdown all updating and ceases network activity. Upon resume, it will wake up and reconnect where possible.
I’ve done another code review and found some more issues with my code and now I’m of the view that I may have now found the root cause of these issues. Are you happy for me to push out another release which might actually resolve this? or would you prefer a beta release for you to test before another public release?
Which ever way is better for you. If I still have the issue I’ll let you know. I was just expecting a beta the other day. But either way is fine by me.
I can push out a beta mobile/tablet release to the test Android and Apple users in the least amount of time, so if you can test today and confirm that it looks good, I can then continue with a build for all the other platforms as a formal release to public.
Build 15117 (v1.5.3) has been pushed out to the test channels of PlayStore and TestFlight for those of you with beta access to hubiVue (for mobile/tablets).
I do feel somewhat confident about this fix because it was definitely not resuming correctly for mobile devices that can put the app to sleep (which is the case with what @LCW731 and @dcoghlan have reported). I also now correctly parse the HSM and Mode status updates within the faster eventsource API.
Fingers crossed I’ve put this bug to bed once and for all !!
I’m also having the lag. I have to wait so long for the HSM tile to go functional, I’ve resorted to using my keypad, where before it was faster to whip out my phone and use Hubivue
Would you all be able to report to me what version of Hubitat you are using? The software version etc.
I’m seeing very, very low levels of eventsocket data being sent to your device - it is like as if the hub is unable to send event data (or is configure not to do so).
I’m testing this against 2.3.4.128 and that release has a fair number of issues relating to cpu of the hub being overwhelmed etc.
I wonder if we are seeing a problem with eventsocket such that this is what can occur.
Okay, so maybe the correct action is here is for me to remove the new faster event code, have an “advanced mode” option that you can turn on/off to use this as it seems to be “not supported” by Hubitat officially as a method to reduce the slow polling that I was using before.
I made a change to use WebSockets, and when it works, it is way, way faster and means I don’t have to continuously poll the hub when connected locally - but obviously it isn’t working consistently for people. That is a shame.