That ping functionality sounds good.

Can I also further suggest a specialised button widget that indicates connected/disconnected status, and connects/disconnects when pressed.
This would allow the UI design to explicitly address connectivity (or, of course, to leave such issues to the existing implicit mechanisms.)

And thanks for pointing out the side-swipe menu access - I now see it's documented in the manual in Fig 2. Mentioning it in the text that follows might help emphasise this (and give careless readers like me a second chance to catch it).

Actually, I wonder if this suggests a second specialised button widget, that opens this menu (independently of the target).

Cheers

@kl3m3n

My setup is an RP2040 target (running LWIP), talking to an Android tablet (not sure brand/flavour, don't have it to hand right now). I do not have autoconnect enabled.

I've observed that if the connection is interrupted abruptly (e.g. power loss to the target), the GUI doesn't react at all, even when interacting with UI elements - at least, not in any meaningful timeframe (tens ot seconds - I haven't tried waiting longer).

However I did notice something that I'll need to test further to more accurately describe: after leaving things connected overnight, when next I looked the GUI was either already displaying a 'lost connection' message box, or displayed one after I pressed a Button element. (Sorry, can't remember now exactly whch case it was, will need to re-test.)

In any case, after dismissing the message box, the GUI remained in place (i.e. didn't revert to the menu screen or offer to reconnect). Further interaction with the UI produced no reaction.

(And while I think of it: I can't see a way to return to the main menu screen from a UI page, other than having the target issue @quitapp in response to a button press - which is great, but only works if the target is connected and responsive. The rest of the time I have to actually switch away from the app altogether and relaunch it.)

I see that @ping allows the target to confirm presence of the GUI - perhaps a command can be added that activates an equivalent mechanism from the GUI. Or configuring TCP keepalive (including timing) at the GUI end of the connection.

I'll do some more testing and try to provide further details.
Thanks

I'm using the simple TCP connection type, and it appears that the app doesn't notice when the connection to the device is lost.
Even using the UI doesn't cause the app to indicate connection loss when it attempts to send an event.

Am I correct, or have I missed something?