add a helper function test bridge connectivity

[jonoberheide]

Hi there! I'm trying to resolve home-assistant/core#110067

@bdraco suggested having separate timeouts in HA-land for the connection phase vs the full-loading phase of all the leap requests/zones/etc. I'm finding that approach challenging as the _connect() logic is so intertwined in the Smartbridge state machine. Instead, a more simple approach may be to define a helper function that tests connectivity to the bridge, which HA can call to verify connectivity and report any issues back to the user, before the full load which will be given a longer timeout (BRIDGE_TIMEOUT) for large QSX deployments.

[jonoberheide]

Ping, any thoughts here?

[mdonoughe]

I don't understand the purpose of this function. If Home Assistant needs to know that progress is being made, shouldn't the regular connection code be sending some sort of event back to say that it's progressing? This function creates a different connection and immediately closes it, which doesn't mean the next connection will complete in any amount of time.

[jonoberheide]

I don't understand the purpose of this function. If Home Assistant needs to know that progress is being made, shouldn't the regular connection code be sending some sort of event back to say that it's progressing? This function creates a different connection and immediately closes it, which doesn't mean the next connection will complete in any amount of time.

Right now, Smartbridge.connect() does more than connect, it also loads all the devices/zones/etc from the bridge. This can take a very long time on large deployments, exceeding HA's timeout (BRIDGE_TIMEOUT, see home-assistant/core#110067). Simply increasing the timeout in HA was not recommended, since if there was some other connection-level issue, we would not want to wait that long.

So two other options are: (1) this PR here where we add a connection test function to ensure reachability, correct creds, etc, which then gives us confidence to increase the timeout and assume the library taking a long time is actually due to it loading all the zones/devices/etc. Or (2) break library API compatibility and separate out the steps into more discrete Smartbridge.connect() and maybe Smartbridge.load()/Smartbridge.monitor() steps so that, again, we can have a short connection timeout, but a much longer loading timeout.

Agreed (1) is kind of a weird workaround, but avoids the API breakage of (2). Maybe there's a (3) I'm not thinking of... :-)