GUI-O Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Connection status?

    Scheduled Pinned Locked Moved
    General Discussion
    2
    5
    49
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jeremy0
      last edited by

      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?

      K 1 Reply Last reply Reply Quote 0
      • K
        kl3m3n @jeremy0
        last edited by

        @jeremy0 Hi!

        In TCP connection, GUI-O is the client and should detect disconnection from the server. Furthermore, if "autoconnect" is enabled it should periodically try to reconnect.

        Can you give more information about your setup, so i can try to reproduce the issue you are describing?

        Best regards,
        Kl3m3n

        J 1 Reply Last reply Reply Quote 0
        • J
          jeremy0 @kl3m3n
          last edited by

          @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

          K 1 Reply Last reply Reply Quote 0
          • K
            kl3m3n @jeremy0
            last edited by kl3m3n

            @jeremy0 Hi

            Thank you for the detailed explanation. If you can do more tests, that would be great! If I can reproduce your issue I will be able to solve it more quickly.

            Meanwhile, I will think about how to improve the user experience in such cases. I can't remember exactly, but I think that I wanted to keep the UI after error for some reason.
            BTW: The ping idea seems a valid proposition. I could add an option to enable a "heartbeat" message, which would then use the current @ping -> @pong functionality. The app will expect a periodic ping from the controller (after receiving first message) and send a response - just like now, but it would also disconnect with an error message if ping is not received within the specified interval.

            If you enable autoconnect, GUI-O will try to periodically re-establish the connection. Without autoconnect, it just latches the error.

            @jeremy0 said in Connection status?:

            (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.)

            Try swiping from the left to right (edge of screen) to open the settings menu. Then press the "home" icon on top-right of the screen. This will clear the UI and return you to the "home screen".

            Best regards,
            Klm3n3

            J 1 Reply Last reply Reply Quote 0
            • J
              jeremy0 @kl3m3n
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • First post
                Last post