iOS Apps = iPhone and iPad
Version = v1.5.4
Hubitat Version = 2.3.5.101
Every time I do a fresh “launch” of the app, I get a black “Hub Offline” screen that flashes for about a second and disappears.
If I leave the app running in the background, no issues. This just happens upon launch.
Happens when I’m on my Wi-Fi network at home and via cellular.
If this is not a bug, can something else happen on launch? Perhaps just launch into the dashboard screen and have some type of indicator the dashboard is initializing?
Thanks, happy to provide more information if needed.
Hi,
Probably not a bug.
But before we go further, can you outline how long the delay is before it connects?
Normally it isn’t very long, and only on the first time it connects/starts up
If you hide and then resume, it shouldn’t do that.
Let us know or send a video link of the process so we can confirm
Here’s the link showing the behavior:
So from the look of the video, it would be around 250ms…maybe 500ms at stretch.
Note that it is only occurring when you end/exit the app and start. Subsequent restarts (or resumes) from running don’t exhibit this behaviour (as they are already connected and active).
The app does not have any “previous connection state” to rely on, so it starts assuming it is disconnected / hub offline - which is the same if you removed the wifi services (or disconnected the hub, or walked to a location where there is no WiFi / 4G etc). After a period of time it would go offline (and then if you returned to a network present state, it would eventually connect again).
This is behaving as designed. What would you prefer the behaviour be?
I coold look at how viable it is to start in the “connected” state, which would show the dashboard and if no connection starts it would eventually timeout. Note that obviously that’s a bad/incorrect way to start the app (ie Windows or macOS doesn’t start showing you the last desktop it had and then boot eventually coming active etc - they all start with blank/startup screen when beginning - in fact all apps essentially do that on startup).
If you want the app to start without the delay, what’s wrong with just keeping the app running? Why are you exiting/closing the app?
Probably would have just taken this offline through a PM, but it doesn’t look like I can.
I’ve been evaluating this app and I’m considering using it for future customers. The thing that stood out to my partner and I was this particular aspect of the user experience. If I demo or show someone this app, and upon launch they see ‘Hub Offline’ - it looks like an issue with the app and doesn’t instill confidence. We could also foresee people seeing this message sending us concerned requests about it.
If there’s a more elegant way to start-up the app than showing ‘Hub Offline’ because of where I’m coming from perspective wise, that would be my suggestion. For fun, I launched several apps I have downloaded on my iOS device to see how they deal with this. It looks like they start with a basic splash screen and as soon as the app is loaded, launch into it. Your app could be architected different and may not allow for this. By no means am I any expert to solution this.
Appreciate you listening to my feedback and perspective. I’m a fan of this app so far and definitely appreciate the hard work you’ve put into it. I hope you will take this into strong consideration.
I thought I was the only one who noticed / was bothered by the “HUB OFFLINE” announcement. To me, it’s jarring in much the same way that my TLC television announces “No Signal … Is It On?” when I switch over to the HDMI connector from my computer. YES, IT’S ON! Things just haven’t synced up yet.
So, if you’re going to display a message (of any kind…which I’m perfectly happy not to see), I’d prefer it be something along the lines of “CONNECTING…”. If things go belly up, hit me with a “CONNECTION FAILED” later.
But at the very moment of app start, I want to be blissfully ignorant. 
No worries. Let me look into what can be done to help. I’ll put this on the roadmap and I’d only ask you vote to support where this sits amongst other improvements to be made.
1 Like
Found a simple way to add this. So it’s going to be in the next release.
3 Likes
Sweet, thank you good sir. Look forward to the next release!
1 Like
So I take it the new release has fixed/resolved the issue you had ?
Note I’ve also found a bug in the cache of settings such that sometimes the app was incorrectly reloading the config when there was no change (and thus it was doing it at startup everytime). So another startup issue is resolved whereby it will be even more silky smooth if you’ve exit and restart. This last fix will be applied when the app goes out of beta (as it requires a backend change to be applied at the same time)
1 Like
Wanted to give it a day…looking good!
1 Like
This behavior just came up for me today. Good find, thank you.
Just note that it will do that at times when the configuration has been modified since the last time it was cached - so it will occur from time, to time. Just that I found a bug that was making it occur on EVERY time the app was starting, so unless you’re seeing it occur always, then what you saw was the occassional refresh due to an cache change from either the app or the cloud not being equal.
1 Like
Gonna ask this from a different angle: Would HV benefit from a user having a “Heartbeat” rule running on his hub? For example – I’m just thinking out loud here – a rule that sends out a specific URL (to hubiVue server) every 30-60 seconds, containing the hub ID (or some other unique identifier).
I don’t know where this is going . . .
That won’t help much, as the app rarely connects to the cloud (hubiVue Servers) and more regularly connects directly to the hub. The hub CANNOT connect to the app (as that would mean your phone/tablet/desktop is running a server which they can’t do) either.
End of the day, the regular polling that hubiVue does to confirm config status, and hub connectivity works without much interuption. Obviously if you update the config, any other hubiVue app needs to update that config and refresh itself to ensure it is running the latest equal configuration.
1 Like
