Improve experience when reconnecting after device getting out of sleep

[rchl]

Currently, when TileBoard is opened after the device is woken up from sleep (or the browser is re-opened) the experience is not very smooth as:

• all tiles might be hidden until a few seconds later
• the might be various notifications related to connection errors popping up

We should try to improve that. We could for example:

• have a subtle loading indicator that shows up on initial loading or on reconnecting
• if the tiles were already shown, try to keep all tiles showing on disconnection or connection error and instead either dim them out visually or have some overlay to make it clear that UI is not usable.

[rchl]

Before doing anything, I think it would be worth investigating how browser behaves when the page is being "suspended". I think the behavior might be a bit surprising in that the JS might trigger intervals that didn't run while the page was suspended (or something weird like that).

[resoai]

I agree. Visually I would think that we could have a two-stage loading, when we are keeping all tiles but dimming them slightly and if first reconnection is successful, than we animate the overlay out. If, however, first attempt was unsuccessful, we could show reconnection notification. We also have a problem of notifications spamming like crazy when HA is down or rebooting, perhaps we could add an interval timer there.

[utech-git]

Here's an idea: is it possible to make tileboard send a command to create another socket or to keep one open? With that, we could create an automation on HA that executes this command every now and then. Like, every minute or so.

With Fully Kiosk Browser, we could even create the automation this automation in a way that it is only executed when the screen is off (FKB sends a MQTT message when the screen is turned on/off, as well when it goes to screensaver/daydream).

[rchl]

@utech-git What would be the point of that and how would that address the issue? Do you want to prevent a device from going to sleep? If so, then that is probably already possible by changing the Fully settings?

But this issue is not about preventing sleep but improving handling when going out of sleep.

[utech-git]

The problem is caused because the socket is closed, right? (that happens when the device goes to sleep mode).

The suggestion I made would prevent the socket from closing (or opening a new one) when the devices on sleep mode.

[rchl]

The socket is not closed by TileBoard or HA but by the browser or indirectly by the device itself. So opening more connections wouldn't change anything. There are heuristics implemented in browsers (and android too I guess) to minimize work done by background pages or apps. You wouldn't want your ad-ridden news site to silently consume resources while being in the background right? TileBoard is not an exception here.

[utech-git]

Ohhh i see. I used lovelace interface on Fully Kiosk Browser before TileBoard and I was almost sure that this situation didn't happen on lovelace. I thought it was something specific for tileboard.

But I just made a test with lovelace again and indeed it happens too (althought the "refresh" time for lovelace is quicker).

Thanks for the clarification.

[akloeckner]

Might be related, or not: I have a sensor that changes frequently. I noticed that, when I re-open the browser after minimizing it, the sensor replays multiple values very quickly before it stabilizes. It appears as if there was a buffer of messages that is only processed after waking up the app.

[rtsam]

Might be related, or not: I have a sensor that changes frequently. I noticed that, when I re-open the browser after minimizing it, the sensor replays multiple values very quickly before it stabilizes. It appears as if there was a buffer of messages that is only processed after waking up the app.

Same issue here. So at least I am not the only one. When the tablet wakes up it has a seizure of tiles turning on and off, gauges jumping etc. Until it catches up to current state.

[rchl]

We shall look into it as part of this issue.

We maybe should explicitly disconnect from the API but we could only do that if we would get an event that the device is going to sleep and I don't think there is one.

Or maybe there is another way to skip UI updates but we would need to figure out how this particular case can be detected and special-cased.

[rtsam]

I wonder if you could use time/ping/heartbeat as a factor. For example if there is a large gap you know that you are coming out of sleep. And to ignore the update stream of events and reconnect only getting the current state.

Disclaimer: I have no idea how the api works. :)

[akloeckner]

Another idea (under the same disclaimer), we could maybe debounce the updating of the view after each incoming state change. That way, all state changes should be updated at once. (Possibly, the custom watcher for history charts will have to be adapted to that.)

PS: Possibly debounce that function here, simply? https://github.com/resoai/TileBoard/blob/40a5d70b7b26edf580a72053e05aab201e75cb1a/scripts/controllers/main.js#L2309

[rchl]

There is work to be done to actually understand what is happening here.

When the tileboard was unused did the browser suspend the page completely? I guess not since then the websocket connection would not receive changes and try to "reply" them after waking up. But then what was actually preventing it from applying those changes to the UI right away? Are UI updates driven by requestAnimationFrame, for example, making them only happen when the page is activated?

But this is probably only one of the possible cases. I think the browser can also suspend the page in which case no updates will be received and then TileBoard will re-connect web socket connection on being woken up. In that case, there should be no changes being "replied".

[rtsam]

Just to give background on my setup.

Using a Fire HD tablet, all power features are disabled. Fully Kiosk Browser I can ping the tablet while it is sleeping, and the FK admin page is usable. So the tablet and app itself are responding. Pause Webview while in Background (experimental) is disabled. (this was the only setting I could find referring to sleeping/pausing)

Tileboard screensaver is commented out (default configuration)